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Intellectual Property Rights 
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pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by ETSI Project Digital Enhanced Cordless Telecommunications 
(DECT). 

The present document is based on DECT Common Interface (CI) specification EN 300 175, parts 1 [1] to 8 [8] to 
enable DECT terminals to interwork in the public and private environment when connected to an IP network. 

In addition, for the purpose of interoperability and wherever it is found appropriate, the present document takes into 
consideration the requirements of: 

• the DECT Generic Access Profile (GAP), EN 300 444 [13] to enable the same DECT portable part (PT) to 
interwork with a DECT fixed part (FP) complying to the GAP requirements, irrespective of whether this FP 
provides residential, business or public access services; 

• the DECT Packet Radio Service (DPRS), EN 301 649 [16] to enable DECT data terminals to interwork with a 
DECT FP complying to the DPRS requirements, irrespective of whether this FP provides residential, business 
or public access services. 

General attachment requirements are based on EN 301 406 [15]. 

Further details on the DECT system may be found in TR 101 178 [1 1], EN 300 176-1 [9] and EN 300 176-2 [10]. 
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Scope 



The present document specifies additional requirements for DECT Internet Protocol (IP) applications including 
networking aspects. Voice over IP (VoIP) and other multimedia exchange over IP, mobility and quality of service 
properties. 

It provides an end system, i.e. termination of IP into the DECT Fixed Termination (FT). 

NOTE: Transparent IP packet service is described in EN 301 649 [16], DPRS standard. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 
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Interface (CI); Part 4: Data Link Control (DLC) layer". 
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Interface (CI); Part 5: Network (NWK) layer". 
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[12] ETSI TR 102 010: "Digital Enhanced Cordless Telecommunications (DECT); DECT access to IP 

networks". 
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[13] ETSI EN 300 444: "Digital Enhanced Cordless Telecommunications (DECT); Generic Access 
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[14] ETSI EN 300 824: "Digital Enhanced Cordless Telecommunications (DECT); Cordless Terminal 

Mobility (CTM); CTM Access Profile (CAP)". 
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Digital Enhanced Cordless Telecommunications (DECT) covering essential requirements under 
article 3.2 of the R&TTE Directive; Generic radio". 

[16] ETSI EN 301 649: "Digital Enhanced Cordless Telecommunications (DECT); DECT Packet 

Radio Service (DPRS) ". 

[17] IETF RFC 3344: "IP Mobility Support for IPv4". 
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[32] ETSI TS 102 342: "Digital Enhanced Cordless Telecommunications (DECT); Cordless multimedia 

communication system; Open Data Access Profile (ODAP)". 

3 Definitions, symbols and abbreviations 

Generic DECT definitions, symbols and abbreviations can be found in the base standard EN 300 175-1 [1]. 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in EN 300 175-1 [1], RFC 3344 [17], 
RFC 3261 [18] and the following apply: 

DECT User Agent (UA): logical entity comprising the SIP functionality provided by the DECT Fixed Termination 
User Agent (FT-UA) and DECT Portable Termination User Agent (PT-UA) 

NOTE: Physically it includes one DECT FP and one or more DECT PPs. 
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netmask: string of O's and I's that mask out the network part of an IP address(IP) so that only the host computer part of 
the address remains 

NOTE: A 32-bit bit mask shows how an Internet address is to be divided into network, subnet and host parts. A 

frequently-used netmask is 255.255.255.0. (255 is the decimal equivalent of a binary string of eight ones.) 
Used for a Class C subnet (one with up to 255 host computers), the ".0" in the "255.255.255.0" netmask 
allows the specific host computer address to be visible. 

session ID: <Call-ID> field in a SIP message as defined in RFC 3261 [18] 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 



M 
O 
I 

c 

N/A 



mandatory to support (provision mandatory, process mandatory) 

optional to support (provision optional, process mandatory) 

out-of-scope (provision optional, process optional) not subject for testing 

conditional to support (process mandatory) 

not applicable (in the given context the specification makes it impossible to use this capability) 



Provision mandatory, process mandatory means that the indicated feature service or procedure shall be implemented as 
described in the present document, and may be subject to testing. 

Provision optional, process mandatory means that the indicated feature, service or procedure may be implemented, and 
if implemented, the feature, service or procedure shall be implemented as described in the present document, and may 
be subject to testing. 

3.3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AC Access Code 

ACK ACKnowledge 

ADPCM Adaptive Differential Pulse Code Modulation 

AOR Address-Of-Record 

AP Access Point 

ARI Access Rights Identity 

BOOTP BOOTstrap Protocol 

CAP CTM Access Profile 

CC Call Control 

CI Common Interface 

CTM Cordless Terminal Mobility 

DCK Derived Cipher Key 

DECT Digital Enhanced Cordless Telecommunications 

DHCP Dynamic Host Configuration Protocol 

DIMS DECT IP Mobility Signature 

DEC Data Link Control 

DPRS DECT Packet Radio Service 

EN European Norm 

FA Foreign Agent 

FP Fixed Part 

FT Fixed Termination 

FT-UA Fixed Termination-User Agent 

GAP Generic Access Profile 

HA Home Agent 

HFP Home Fixed Part 

HFT Home Fixed Termination 

HMAC Hash function based Message Authentication Code 

HTTP HyperText Transfer Protocol 

ID IDentifier 

IETF Internet Engineering Task Force 
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IP Internet Protocol 

IPCP Internet Protocol Control Protocol 

IPUI International Portable User Identity 

IPv4 IP version 4 

IPv6 IP version 6 

IWU Inter Working Unit 

IWU InterWorking Unit 

MAC Medium Access Control 

MIME Multipurpose Internet Mail Extensions 

MM Mobility Management 

MN Mobile Node 

MPEG Moving Picture Experts Group 

MSA Mobility Security Association 

NAI Network Access Identifier 

NLR No Link Request 

NTP Network Time Protocol 

NWK NetWorK 

ODAP Open Data Access Profile 

PBX Private Branch Exchange 

PHL PHysical Layer 

PP Portable Part 

PPP Point to Point Protocol 

PT Portable Termination 

PT-UA Portable Termination-User Agent 

QoS Quality of Service 

RFC Request For Comment 

RSVP Reservation Protocol 

RTCP Real-time Transport Control Protocol 

RTP Real-time Transport Protocol 

RTSP Real-Time Streaming Protocol 

S/MIME Secure/Multipurpose Internet Mail Extensions 

SARI Secondary Access Rights Identity 

SDP Session Description Protocol 

SIP Session Initiation Protocol 

SIPS Session Initiation Protocol Secure 

SMPT Simple Mail Transfer Protocol 

SPI Security Parameter Index 

TCP Transmission Control Protocol 

TLS Transport Layer Security 

UA User Agent 

UDP User Datagram Protocol 

U-plane User-plane 

URI Uniform Resource Indicator 

URL Uniform Resource Locator 

VFT Visiting Fixed Termination 

VoIP Voice over IP 



General 



The main focus of the present document is on DECT interworking with IP mobility (as specified in RFC 3344 [17]) and 
Session Initiation Protocol (SIP) (as specified in RFC 3261 [18]) for the provision of multimedia (including voice) 
services. 

Some of the requirements specified in the present document are relevant only to IP version 4 (IPv4). Support of IPv6 
may be added in future versions of the document. 

Clause 6 provides the reference configuration of the protocols and services relevant for the present document. Clause 7 
specifies the requirements in regard to the services provision. The annexes provide additional information. 
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NOTE: The interworking specification between the FT and the IP is out of the scope of the present document and 
is left to the implementer's choice. Any excerpts form the IP protocols shown in the present document are 
used only as examples. 



Overview 



DECT is a standard for short range, low power, digital cordless communications which provides access to a great 
variety of external (to DECT) networks. 

DECT access to IP networks is already described in the DPRS standard, EN 301 649 [16]. DPRS provides a transparent 
mechanism for exchange of data between an IP network and an IP terminal, or an IP application in a terminal, where 
DECT is used as a cordless carrier for the transport of the data. 

A general introduction to the issues related to DECT access to IP networks is provided in TR 102 010 [12]. 

The present document provides requirements aimed at solving some issues identified in TR 102 010 [12]. 



Reference configuration 



In figures 1 and 2 are shown two possible reference configurations in regard to interaction between DECT FP and PP. 

Configuration 1 is related to the termination of the IP protocol in the PP (which is out of the scope of the present 
document). Such configuration may be useful in case the applications attached to the DECT PT are more general. The 
DPRS standard provides requirements for this case, see EN 301 649 [16]. 
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Figure 1 : Reference configuration 1 (IP terminated at the PP) 
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Configuration 2, figure 2, describes the case when the IP protocol is terminated in the FP (which is into the scope of the 
present document). This configuration may be preferable especially in the case of a DECT voice IP telephone (this does 
not exclude messaging or other data only services). Some issues that need consideration here in regard to providing 
interoperability between FPs and PPs are, e.g. unified way of transmitting the voice samples or other media streams to 
the PP and interaction with the signalling protocol use by the VoIP (e.g. SIP). 
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Figure 2: Reference configuration 2 (IP terminated at the FP) 
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7 Requirements 

7.1 Requirements table 

Table 1 lists the requirements that have fallen into the scope of the present document. Details are provided in the clauses 
that follow. 

Table 1 : DECT access to IP networks requirements 



Item 


Name of service 


Procedure 


Reference 


Support status 


PT 


FT 


DAIP-F.1 


PP IP roaming IPv4 




7.2.1.2 


CI 


CI 






Set up of DECT IP supporting 
environment 


7.2.1.2.2 


M 


M 






DECT attachment/IP roaming 
registration FT handled IP mobility 
authentication 


7.2.1.2.3 


M 


M 






DECT attachment/IP roaming 
registration PT handled IP mobility 
authentication 


7.2.1.2.4 








DAIP-F.2 


FP IP roaming IPv4 




7.2.1.3 


N/A 


CI 






FP IP roaming 


7.2.1.3 


N/A 


M 


DAIP-F.3 


Roaming without IP mMobility 




7.2.1.4 


CI 


CI 






Roaming without IP mobility 


7.2.1.4 


M 


M 


DAIP-F.4 


User roaming 




7.2.1.5 


CI 


CI 






User IP roaming 


7.2.1.5 


M 


M 


DAIP-F.5 


Handover 




7.2.2 


CI 


CI 






Basic requirements 


7.2.2.1 


M 


M 






Automatic assignment of external 
handover related Identities 


7.2.2.2 












External handover call setup 


7.2.2.3 


M 


M 






FP synchronization over the IP network 


7.2.2.4 








DAIP-F.6 


SIP interworking 




7.3 


CI 


CI 






Registration - procedure mapping 


7.3.2.1 


M 


M 






Registration - adding/modifying 
bindings 


7.3.2.1.1 


M 


M 






Registration - fetching bindings 


7.3.2.1.2 












Registration - refreshing bindings 


7.3.2.1.3 


M 


M 






Call Control (CC) 


7.3.3 


M 


M 






Service Attributes 
negotiation/modification 


7.3.4 


C3 


C3 






Security 


7.3.5 


M 


M 






Query for capabilities 


7.3.6 












GAPU-plane(EN300 444[13l) 


7.3.7.1 


C2 


C2 






DPRS U-plane (EN 301 649 [16]) 


7.3.7.2 


C4 


C5 






ODAP U-plane (TS 102 342 [32]) 


7.3.7.3 


C4 


C5 


DAIP-F.7 


QoS 




7.4 


N/A 


C2 






QoS 


7.4 


N/A 


M 


C1 : At least one shall be supported. 

C2: Mif service is VoIP. 

C3: IVI if service is different than VoIP. 

C4: At least on shall be supported if service is different than VoIP. 

C5: At least on shall be supported if service is different than VoIP. 
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7.2 



Mobility 



Figure 3 provides a reference model for DECT-IP mobility with a number of DECT base stations (FPs) connected to 
different IP networks. 




PP 
1 



PP 
2 









PP 

3 


PP 
4 



Figure 3: Mobility reference model 



Basic assumptions: 



1) A PP may move from one FP to another FP when both FPs are connected to one and the same IP network, or 
when each FP is connected to a different IP network. 

2) A FP may move from one Access Point (AP) to another when the access points belong to the same or to 
different IP networks. 

3) An end user may move from one PP to another PP, when each PP is logged on to different FPs, carrying on an 
external media her/his user profile data and providing it to the new PP. 

4) IP is terminated in the FP. Optionally, for some services or special terminals, FP may be transparent in which 
case the DPRS standard shall be used. The mechanism for distinction and utilization of such duality is out of 
the scope of the present document and left to manufacturers own implementation. 

5) How configuration and address allocation is implemented on the boundary between the IP network and the FP 
is out of the scope of the present document, it is assumed that standard, common, procedures and requirements 
(e.g. DHCP, BOOTP, IPCP, Auto configuration, etc.) will be obeyed. 

6) Mapping between assigned IP address(es) and PTs' DECT identities, if needed, shall be managed by the DECT 
FT. The possibility of single terminal maintaining a number of different addresses should be taken into 
account (e.g. global address, link-local address, site-local address, multicast address, care-of-address, etc.). 

7) Depending on the contract initially signed one or more IP addresses may be assigned to be handled at one 
access point, i.e. by one FP. These addresses may be allocated to different PPs or a number of PPs may have 
been allocated a single IP address. The latter case needs special consideration if one of the PPs is to be allowed 
to move to another location. 

8) Each FP may maintain a service record comprising location and service characteristics offered by the accessed 
IP network; for each PP attached to the FP applicability of each of those needs to be indicated, a general 
mechanism for providing the PP with all necessary information may need to be defined. 

9) The IP mobility protocols/solutions differ in regard to the IP version supported, i.e. IPv4 or IPv6. The IPv4 
protocol is described in RFC 3344 [17] and is the only IP version taken into consideration currently in the 
present document. The IPv6 may be taken into consideration in later versions of the document. 
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7.2.1 



Roaming 



7.2.1.1 



General IPv4 



Due to the fact that the present document implies that the IP protocol is terminated in the FT for the basic DECT 
operation the PT needs not be aware of the kind of network the FT is connected to. Therefore, any PP that complies 
with the EN 300 444, GAP [13] shall be capable of operating with an FT that complies with the requirements in this 
clause. However, in order to provide all the services described in this clause PPs may need to comply with additional 
requirements as specified in the present document. 

This clause deals with the requirements which an IP enabled DECT terminal needs to satisfy when moving 
(i.e. roaming) between different IP access points. The term adopted in the IP world for such a terminal is "Mobile Node 
(MN)". According to RFC 3344 [17], a Mobile Node (MN) is "a host or router that changes its point of attachment from 
one network or sub -network to another without changing its IP address and still being capable to communicate with 
other Internet nodes, assuming link-layer connectivity to a point of attachment is available". 

The term "roaming" in DECT is normally related to a PP moving between different FPs, this clause extends the scope of 
the term to include FPs moving between different network access points. 

Due to the fact that the IP protocol is terminated in the DECT FT, whereas the PP can move between different FPs, the 
term Mobile Node (MN) requires a special interpretation. The bases for such a special interpretation are depicted into 
figure 4. 




MN1^P1+FP2.1 
MNl^Pl+FPl.2 {PP roaming) 
MN2^P2+FP1.1 
MN3=(PP3+PP4)+FP1.1 



Figure 4: Mobility reference model 

Accordingly a DECT Mobile Node (DECT MN) is an association between a DECT FP connected to an IP network and 
a DECT PP attached to that FP, where an IP address has been allocated to this tandem. The IP address may be 
associated with the user of this tandem, the PP or the FP. Consequently as shown in figure 4 the tandems <PP1-FP1.2> 
and <PP1-FP2.1> represent one and the same mobile node - MNl, if the IP address has been associated with the user or 
with the PP. In this case when PPl is attached to FP 1.2 (tandem <PP1-FP1.2>), MNl will be present at access point 1 
(AN 1) and connected to IP network 1 (IPl), whereas, when PPl is attached to FP 2.1 (tandem <PP1-FP2.1>), MNl 
will be present at access point 1 (AP 2) and connected to IP network 2 (IP2). 

NOTE 1: If the IP address was associated with the FP, i.e. one IP address with FP1.2 and another with FP2.1, the 

tandems <PP1-FP1.2> and <PP1-FP2.1> would represent different mobile nodes and mobility in this case 
would mean FP moving between different APs. 



ETSI 



1 5 ETSI TS 1 02 265 V1 .2.1 (2004-1 0) 

This definition allows four different DECT-IP roaming scenarios: 

a) PP IP roaming, FPs do not move and the PP roams between fixed FPs taking with it the IP address assigned 
to the initial tandem. 

b) FP IP roaming, FP moves from one access point to another taking with it the IP address assigned to the initial 
tandem (and the subscribed PPs). 

c) Non IP assisted roaming, FPs do not move and the PP roams between fixed FPs NOT taking with it the IP 
address assigned to the initial tandem. 

d) User roaming, the user moves carrying the IP mobility information, i.e. the user profile data, on some kind of 
external media and provides it into a suitable terminal at the new location. 

For scenario a), when a DECT MN roams, it is only the PP part, and not the FP part, of a DECT Mobile Node that does 
move. Consequently: 

• one and the same FP may be part of different DECT MNs; 

• one and the same PP, when roaming, may form associations with different FPs however representing one and 
the same DECT MN identified by the IP address assigned to this PP. 

For scenario b), when a DECT MN roams, it is the FP part of a DECT MN that does move, whereas the PP part may 
move but needs not. At the new access location it is possible that different PPs are in use. It is the FP having assigned 
an IP address and carrying it. 

NOTE 2: A typical example for application of this scenario may be a user moving to a holiday home in which IP 

connection is provided but not DECT cordless access and the user decides to bring her DECT base station 
and portable part with her for the duration of the holiday. 

For scenario c) from the point of view of IP mobility and our definition of DECT MN there is no move of the DECT 
Mobile Node. It is the FP having been assigned an IP address which from the IP network point of view does not move. 

NOTE 3: Scenario c) is provided only for the sake of completeness. It does not provide real user mobility (i.e. one 
portable user access number/address) unless some kind of mapping between the IP address and the PT 
identity is provided on network level. 

Scenario d) may be considered as a variation of either scenario a) - when, depending on the particular terminal 
implementation, at the new location the IP mobility related data is input into a DECT PP, or scenario b) - if the input is 
to a DECT FP. 

The following clauses specify the requirements relevant for each of these scenarios. 

7.2.1 .2 PP IP roaming IPv4 

7.2.1.2.1 General 

DECT PP IP roaming concept is based on, and comprises, a number of interactions as detailed below. 
DECT Mobile Node estabhshment: 

• A PP is DECT registered to a Home FP (HFP). 

• The user has registered with a service provider or network operator and has received one or more IP addresses. 
User name(s) and password(s). In addition the service provider or network operator provides a netmask, a 
Mobility Security Association (MSA), and a Security Parameter Index (SPI) identifying a particular security 
context within the mobile security association (there may be more than one set of parameters belonging to the 
MSA), as defined in RFC 3344 [17]. The MSA includes: a shared key or appropriate public/private key pair, 
identification of the authentication algorithm and mode and the style of Reply protection in use. 
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The user assigns one of the received IP addresses to a PP and by making the FP aware of this assignment the 
user creates a virtual Mobile Node (MN) comprising the PP and the FP. The content of the Mobility Security 
Association and the SPI shall be made available to the MN and may be stored in the PP or/and in the FP. 
Having completed these configurations the user can consider its MN as being registered to the HA or an 
explicit registration procedure may be required. 

The same operation may be done with one or more additional PPs. Each of these PPs identified by its IPUI, its 
IP address, SPI and the relevant Mobility Security Association parameters' values define a virtual Mobile 
Node. It is the FT responsibility to differentiate the MNs it is engaged with and behave proper. 

DECT Mobile Node operation: 

• Before roaming may be attempted a mobile node shall be configured at least with a netmask (subnet-directed 
broadcast address of the mobile node's home network) and a mobility security association for the home agent. 
In addition, a mobile node may be configured with its home address, and/or the IP address of one or more of 
its home agents. The means of configuration are not standardized and manual user input may be required. 
Alternatively, the user may carry all this information on an external media. 

• When PP moves to a FP that supports IP roaming, the PT shall DECT attach to the FT and make the FT aware 
that it supports Mobile IP and would like to engage the FT in a virtual MN. Although each time this DECT 
MN will include a new FP, from IP point of view, it is the same MN because it can be identified (and 
authenticated) with the same set of parameters. Consequently all necessary parameters for correct Mobile IP 
operation need to be made available to the MN (if they are not yet stored in the PT). 

• An FP may be part of DECT MNs that consider the IP network to which the FP is attached as the home 
network, as well as, part of DECT MNs that consider the same IP network as a visited network. A DECT MN 
shall be capable of recognizing that it is attached to a foreign network. The FT shall be capable of discovering 
the address of the local Mobile Agent and obtaining a care-of-address or alternatively obtaining a co-located 
care-of address. (The FT may have already information about the Mobile agents and procedures applied into 
the network as it has been in operation on this network.) 

• If the Home agent address of the DECT MN is not known the FT shall use the netmask to discover it. If the 
MN home address is not provided, the FT shall use the Mobile Node NAI extension RFC 2794 [25] for the 
discovery of the address - to identify itself user shall provide its user name. Optionally, the PT part of the 
virtual MN or the user may provide this information upon the establishment of the virtual MN. Having 
obtained all necessary information the FT shall register with the Home Agent providing its new address. 

• When PP is returning to its home, the home FP shall be capable of recognizing that it is indeed a return to 
home and de-register with the HA. 



• 



• 



• 



During the registration procedure the MN will be authenticated by the HA. The authentication is part of the 
registration, i.e. the data needed for the authentication is provided into the messages exchanged during the 
registration. There are two alternative ways of accomplishing this authentication. The input parameters needed 
for the calculation of the authentication parameters are made available at the FT part and the FT performs the 
necessary calculation, or, the calculation of the authentication parameters is performed into the PT part of the 
virtual MN and the result is submitted to the FT. The former solution is associated with some security risks as 
the visiting user is not in control of the visited FP and by providing to the FT its security information the user 
is vulnerable to this information being misused. Furthermore, the former alternative requires, if the parameters 
are not manually entered into the FT but e.g. sent from the PT, usage of encrypted DECT connection for their 
provision on air. 

Additionally, a MN may have mobility security association(s) as well with a Foreign Agent. In this case the 
FA may authenticate the MN in similar manner as the HA and hence the same issues that was raised in regard 
to HA authentication apply in this case too. 

Virtual MNs (i.e. the FT or/and the PT part depending on the implementation) shall be able to perform 
authentication as defined in RFC 3344 [17]. The defauh algorithm is HMAC-MD5, with a key size of 128 bits 
as specified in RFC 2104 [24]. It computes a 128-bit "message digest" of the registration message. The data 
over which it is computed is the UDP payload (that is, the Registration Request or Registration Reply data), all 
prior Extensions in their entirety (i.e. if any Optional Non-Auth Extensions for HA), and the Type, Length, and 
SPI of the MN-HA Authentication Extension. 
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• In addition to the addresses discovery and the authentication issues the user should be provided with the 
possibiHty to indicate that she/he would like to keep its previously registered mobile addresses (setting the "S" 
bit in the Register message) or delete a particular mobile binding (setting the life time to zero), and/or, that the 
HA shall forward to it a copy of broadcast datagrams received by its home agent from the home network 
(setting the "B" bit in the Register message), and/or indicate a desired life time for the binding (registration). 
Re-registration for the active binding is the responsibility of the FT part of the virtual MN. 

• A registration may be rejected. Some errors may be solved by the user, e.g. spelling errors in regard to 
information entered manually and should be therefore indicated to the user. 

• After registration the normal operation of the virtual MN (in regard to IP interworking) shall be in the 
responsibility of the FT part. 

DECT private use: 

• The PP attachment to a FP usually requires that either the PP is subscribed to that FP (e.g. GAP [13]) or that 
the visited FP has a roaming agreement with the PP's home FP or home DECT network where the PT is 
subscribed (e.g. CAP [14]). When DECT Mobile IP is used in a DECT Public or business network which is 
managed centrally it is very likely that a combination of GAP and CAP like roaming rules will be applied. 
However, when DECT private users are involved care shall be taken to avoid FPs being overloaded with 
requests for IP roaming from visiting PPs, or/and, PPs being unable to provide services when constantly trying 
to attach to FPs. 

The following clauses describe the DECT specific procedures that a DECT PT and/or FT should implement to satisfy 
the DECT IP mobility requirements and perform the interactions described in this clause. 

7.2.1 .2.2 Set up of DECT IP roaming supporting environment 

DECT FPs that comply with the present document shall provide the user (owner) with the possibility to set the FP in 
one of the following IP mobility related modes: 

• IP roaming not allowed (default); 

• IP roaming Personal OR/ AND IP Roaming Managed group; 

• IP roaming unrestricted. 

The mode "IP roaming not allowed" is the default mode. It does not require any IP mobility related settings or 
indications. Terminals that do not provide IP mobility, e.g. straight GAP terminals, are considered as being set to "IP 
roaming not allowed". Terminals that allow IP roaming only if a valid subscription is available are considered, from the 
point of vie of a roaming PP without subscription, as being set to "IP roaming not allowed". 

The mode "IP roaming Personal" allows for the owner of a DECT base station to permit on case by case bases the IP 
roaming of portables (PPs) that are not subscribed to the base station. For the support of this service the following 
provisions shall be implemented: 

• The Base station owner shall be capable of "reading" and providing to the visiting PP the RFPI transmitted by 
the FT. In addition an IP roaming AC shall be set and made known to the FT and to the visiting PT; the 

GAP [13] procedure AC to bitstring mapping shall be supported. A PT subscribed to the FT should be used for 
these purposes. The setting of the IP roaming AC may be used to set the FT in "IP roaming Personal" mode. In 
this mode the FT shall be prepared to handle IP roaming registrations from PTs that know the IP roaming AC; 
no other FT actions are required. 

• The visiting PT shall support the GAP [13] procedures Manual entry of the Park and AC to bitstring mapping. 
PTs shall be able to store at least one pare of IP roaming REP I/AC. 

• A PT is allowed to lock to an FT and register for the purpose of IP roaming if it has stored the FP RFPI/AC. 
The AC shall be used for PT authentication. During the Authentication procedure a DCK should be stored. 
The DCK shall be used for link encryption if IP confidentiality parameters are to be sent over the DECT air 
(e.g. as defined in clause 7.2.1.2.3). 
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The mode "IP roaming managed group" allows for a business or public DECT system to assign a common SARI 
dedicated for IP roaming which may be transmitted by a number of DECT FTs. For the support of this service the 
following provisions shall be implemented: 

• For the IP roaming SARI any DECT identity with the exception of ARI class A and D may be used (see 
EN 300 175-6 [6]). For the SARI provision proprietary configuration means may be used. The SARI value 
shall be given to any PP that is allowed IP roaming to the FTs transmitting the SARI. In addition an IP 
roaming AC shall be set and made known to the FT(s) and to the visiting PT(s); the GAP [13] procedure AC to 
bitstring mapping shall be supported. The setting of the IP roaming AC may be used to set the FT in "IP 
roaming managed group" mode. In this mode the FT shall broadcast the IP roaming SARI and shall be 
prepared to handle IP roaming registrations from PTs that know the IP roaming AC; no other FT actions are 
required. 

• The visiting PT shall support the GAP [13] procedures Manual entry of the Park (used for SARI) and AC to 
bitstring mapping. PTs shall be able to store at least one pare of IP roaming SARI/ AC. 

• A PT is allowed to lock to an FT and register for the purpose of IP roaming if it has stored the FP SARI/ AC. 
The AC shall be used for PT authentication. During the Authentication procedure a DCK should be stored. 
The DCK shall be used for link encryption if IP confidentiality parameters are to be sent over the DECT air 
(e.g. as defined in clause 7.2.1.2.3). 

The mode "IP roaming unrestricted" allows for the owner of a DECT base station to permit any PP to attach for the 
purpose of IP roaming. For the support of this service the user shall be capable of setting the FT to start broadcasting 
"IP roaming unrestricted" in the Extended Fixed Part Higher layer Capabilities MAC message (see EN 300 175-3 [3] 
and EN 300 175-5 [5]). In this mode the FT shall allow bearer setup and IP mobility attach procedure initiated by any 
PP and shall not authenticate the PT. 

NOTE: The FP owner of such a FP should be allowed to set up priority handling or restrictions among visiting 
and home MN. The means of setting up such schemes are out of the scope of the present document. 

In addition to the requirements related to setting up the environment to allow a PP to roam each such a PP requires the 
availability of a number of parameters that will be used during the IP Mobility Registration (described in the following 
clauses). For this purpose a PT should implement an IP mobility data information structure in which all parameters 
needed and supported for a correct IP mobility operation are stored. The exact implementation of this data structure, 
called in the present document as the "DECT IP Mobility Signature (DIMS)", is left to the implementer's choice. 
Table 2 identifies the relevant parameters and the status of their provision. 

Table 2: DECT IP Mobility Signature (DIMS) 



Nr. 


Data 


Nr. of bits 


Status 


Comment 


1 


IVIobile IP bindings properties. Settings 


8 


M 


See notes 1 , 5, 6 


2 


IVIobile IP bindings properties. Lifetime 


16 


M 


See notes 5, 6 


3 


Home Address (IPv4) 


32 





See note 6 


4 


Care-off address (IPv4) 


32 







5.1 


Netmask 


nx8 


M 


See note 2 


5.2 


Agent address (IPv4) 


32 





See note 6 


5.3 


Security Parameter Index (SRI) MN-HA 


32 


M 




5.4 


Mobility Security Association. Auth algorithm 


4 


M 


See notes 3, 5 


5.5 


IVIobility Security Association. Reply protection 


4 


M 


See notes 3, 5 


5.6 


IVIobility Security Association. Secret 
Authentication Key 


128 


M 




5.7 


Username 


nx8 


C 


See notes 4, 6 


NOTE 1 : This field represents the S|B|D|IVI|G|r|T|x|, see RFC 3344 [17] bits. User shall be allowed 

to set the values of bits "S" and "B". 
NOTE 2: The provision of one set of the fields 5.1 to 5.7 is mandatory to cover the data related to 

one Home Agent. An implementation may allow provision of multiple sets to cover 

multiple Home Agents and Foreign Agents authentication. 
NOTE 3: To indicate the exact option chosen. 
NOTE 4: "Username" is required if no Home Address is provided. 
NOTE 5: A default setting needs not be indicated. 
NOTE 6: An implementer may choose to request this information dynamically from the user rather 

than storing it. 
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The means for establishing all necessary information to be included into the DIMS on the first place is out of the scope 
of the present document. Some of the information may be provided to the Home FT (HFT) over the IP network where 
proper IP configuration protocols may be implemented. Some information, if not all, may require manual input. 
Implementers shall provide means for manual input at the PP - those are out of the scope of the present document. 

The minimum set of parameters from those indicated in table 2 that need to be available at the PT side for IP 
roaming are: 



5.1 
5.3 
5.4 
5.5 
5.6 
5.7 



Netmask 

Security Parameter Index (SPI) MN-HA 

Mobility Security Association. Auth algorithm 

Mobility Security Association. Reply protection 

Mobility Security Association. Secret Authentication Key 

Username 



All PPs that claim support of IP Mobility as described in the present document shall be capable of accepting manual 
input and over the DECT-air interface input for establishing of its DIMS. FPs that support configuration over the IP or 
other "direct" means (e.g. wired interface) shall be capable of providing the established information to the PT over the 
DECT-air interface; FPs that do not support such configuration shall be capable of accepting and configuring such 
information over the DECT-air interface provided from a suitable PT. 

It is PT responsibility to establish the DIMS. If the user has been provided with some DIMS parameters on external 
media those shall be entered to the PP manually. 

If some of the parameters are missing and those needs to be downloaded from the FT over the air the DECT Parameter 
retrieval procedure as specified in EN 300 175-5 [5], clause 13.7 shall be used. The «Info Type» information 
element in the {MM -INFO-REQUEST} message shall be set to "Dynamic Parameters Allocation" and "IP Mobility 
DIMS" shall be indicated in a «IWU-TO-IWU». If a "Username" and/or "Netmask" have been allocated this shall be 
included in the «IWU-TO-IWU» as well. 

Upon the receipt of the request FT shall provide back any parameter available using the «IWU-TO-IWU» in a 
{MM-INFO- ACCEPT} message. Depending on the implementation the FT may try to obtain some parameters from 
external sources. If the FT is not capable of providing any parameter but supports IP Mobility it shall send back a 
{MM-INFO- ACCEPT} without parameters. If the FT does not support IP mobility it shall reject the request with a 
{MM-INFO-REJECT} message. At the PT side if a {MM-INFO-REJECT} is received or timer <MM-info.l> expires 
without an answer being received from the FT the PT should consider that the FT does not support IP roaming and 
inform the user respectively. If the Secret Authentication Key is to be transmitted over the air the DECT link shall be 
ciphered before hand - the FT initiated Ciphering as specified in GAP [13] shall be used. 

For the structure of the «IWU-TO-IWU» information element in regard to IP mobility see clause 7.2.1.2.5. If the 
inclusion of the «IWU-TO-IWU» will result in a message longer than 63 octets, the «IWU-TO-IWU» shall be 
segmented in one or more {MM-IWU} messages. PT shall restart timer <MM_info.l> after sending every {MM-IWU} 
message. To allow sending/reception of {MM-IWU} messages after the last message of a MM procedure has been 
sent/received the MM entity shall indicate "partial release" in the NLR notification as specified in EN 300 175-5 [5], 
clause 14.2.7.2. 

Table 3: Values used within a MM message 



Information element 


Field within the information 
element 


Standard values within the 
field/information element 


Normative 
action/comment 


«Segmented lnfo» 






See note 2 




<Segmented element type> 


1110111 


«IWU-TO-IWU» 


«IWU-TO-IWU» 




All 


See note 1 


NOTE 1 : For the content of the «IWU-TO-IWU» information element see clause 7.2.1 .2.5. 

NOTE 2: IVIandatory only if the message will exceed 63 octets or when «IWU-TO-IWU» was segmented. 



7.2.1.2.3 



DECT attachment/IP roaming registration FT handled IP mobility authentication 



All terminals complying with the present document shall support the "FT handled IP mobility authentication" and the 
related procedures as described in this clause. Optionally terminals may support PT handled IP mobility authentication 
and the related procedures as described in clause 7.2.1.2.4. The user shall be informed for the possible security issues as 
indicated in clause 7.2.1.2.1. 
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All FPs shall support in fall the requirements of the Mobile IP Mobile Node as specified in RFC 3344 [17]. For the PP 
implementation the requirements of the RFC 3344 [17] are not applicable. 

The IP roaming registration procedure shall be mapped to DECT Location registration and possibly DECT location 
update procedures as defined in GAP [13] with the modification specified in this clause. 

The FT handled IP mobility authentication implies, as indicated in clause 7.2.1.2.1, that all parameters involved into the 
authentication procedure during the IP mobility registration with a HA or FA shall be made available into the FT prior 
to the construction of the IP Mobility Registration message. 

For the provision of the DIMS to a visited FP (which can be used with HFP also) there are three alternatives identified: 

direct (manual) input to the FP; 

local PP-to-FP provision (manual entry into the local PP); and 

visiting PP-to-FP provision (automatic). 

A designer may choose to implement a kind of direct input to the FT. This implementation is out of the scope of the 
present document. 

If direct input to the FT is not provided a DECT on-air exchange between the FT and a PT shall be used. The 
transmission should be made over an encrypted DECT link. 

The designer may choose to implement such exchange to be assisted (performed) by a local PP already subscribed to 
the FT and the user will be expected to provide the information to be keyed into the PP. 

To support manual entry of parameters, either directly into the FT or into the local PT, all PPs that claim support to the 
present document shall be capable on user's request to display the PP's IP mobility parameters allowing for the user to 
read them from the visiting PP and key them into the local PP that will transmit them to the FP. If such procedure is 
implemented the designer should take care that the provision of the information is guarded by local to the PT PIN (user 
password). 

Independent of whether a manual entry to the FT is supported, to ensure interoperability among terminals from different 
vendors every PT that claims support to the present document shall support the Local PP-to-FP provision procedure. 

Alternatively, the visiting PT may itself provide the parameters to the FT. The support of this procedure is optional. It 
should be noted however that this is the only way that a PP may roam without user intervention into already set up IP 
mobility environment for which the PT knows the setting parameters. 

Whichever of these three options is implemented the user shall be provided with the capability to request IP mobility 
registration. Optionally a roaming PT may prompt the user to start the registration upon entering an IP mobility allowed 
area. Automatic registration may be implemented as well allowing fro the PT to start registration as soon as it 
recognizes an area in which the IP mobility for this PT is allowed. 

The PT shall initiate an attach (roaming registration) procedure using the GAP Location registration procedure as 
defined in [13] providing at least its netmask address and optionally its IP home-address and/or HA address. If Home 
address is not provided the User shall provide its User name. Mobile IP bindings properties may be provided as well 
(see DECT IP Mobility Signature (DIMS) above). 

Upon receipt of the {LOCATE-REQUESTj message the FT shall behave depending on the information available: 

1) If the visited FT (VFT) does not have a record of the PT's IP mobility authentication parameters and if a 
roaming security key is available the FT shall initiate a DECT authentication procedure using the AC (the 
roaming security key) indicating that DCK shall be stored. If the authentication is successful the FT shall 
initiate FT initiated ciphering procedure as defined in GAP [13]. After the link is ciphered the FT shall request 
transmission of IP mobility authentication parameters and PT shall provide them in a «IWU-TO-IWU» 
information element included in a {MM-IWUj messages which shall not exceed the length of 63 octets or the 
«IWU-TO-IWU» shall be segmented in a number of {MM-IWUj messages. If HA address has not been 
provided the FT shall perform as soon as possible HA address discovery as specified in RFC 3344 [17]. The 
FT shall proceed with step 4. 



£75/ 



21 



ETSI TS 102 265 V1.2.1 (2004-10) 



2) If the visited FT (VFT) does not have a record of the PT's IP mobility authentication parameters and if a 
roaming security key is not available the FT shall reject the Location registration procedure providing 
indication to the user for the reason. The procedure shall be rejected as well if not sufficient address 
information has been provided. 

3) If the visited FT (VFT) does have a record of the PT's IP mobility authentication parameters it shall proceed 
with step 4. If HA address has not been provided the FT shall perform as soon as possible HA address 
discovery as specified in RFC 3344 [17]. 

4) After the VFT obtains all information needed it shall initiate a Mobile IP registration procedure as defined in 
the RFC 3344 [17]. If User name was provided instead of a Home address the FT shall follow the requirements 
specified in RFC 3344 [17] and RFC 2794 [25] for the construction of the Registration message. When the 
registration is completed the VFT shall confirm this to the PT by sending back a { LOC ATE-ACCEPT } 
message. Any not provided by the visiting PT but discovered by the FT address should be stored for future 
use. 

If the completion of the procedures on the IP side is taking time longer than the time allowed for the completion of the 
DECT Location registration procedure the VFT shall used the { MM-NOTIFY } to restart the running at the PT timer 
associated with the attach procedure. 

Figure 5 shows an example of a complete PP IP roaming registration procedure. It assumes that: Roaming has been 
enabled at the FT (i.e. Roaming RFPI and Roaming security key available at the FT and at the PT). 



PT1 



VFT 



< 



Roami ng 
allowed=Yes 



> 



LOCATE-RBQ UEST (nelmask. user nane) 



AUIH-RBQUBS T (ac, store dck) 



AUTH-REPLY 



CIPHER-REQUEST 



. linkciphered 

MM-IWU (aiith data leq) 



MM-IWU(aulhdala) 



MM NOUFY (timer restart) 



LOCAIE-ACCEPT 



HA 



HA address 
discovery 



FA 



Registration HA (NAI) 



[RELAY] Replay 



[RELAY] Registration HA 



Replay (MN Home Address) 



Figure 5: Successful PP mobile IP roaming registration (FT auth) 

The DECT message/information elements support required in addition to the requirements of GAP is indicated into 
clause 7.2.1.2.5. 



7.2.1.2.4 



DECT attachment/IP roaming registration PT handled IP mobility authentication 



All terminals complying with the present document may optionally, in addition to the requirements provided in 
clause 7.2.1.2.3, support PT handled IP mobility authentication and the related procedures as described in this clause. 

NOTE 1 : The main target of the requirements in this clause is to provide a solution for some security concerns 
indicated in clause 7.2.1.2.1. 
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IP mobility authentication as specified in RFC 3344 [17] is based on the performing of calculations (using the Mobility 
Security Association parameters) applied over parts of the Registration message and including the result of this 
calculation together with the SPI in the message before sending it to the HA (FA). Consequently, the PT handled IP 
mobility authentication does not require full implementation of the RFC 3344 [17] into the PT rather it is based on the 
requirements that all IP mobility handling is done into the FT except that the calculations over information available in 
the PT and such provided by the FT to the PT are done into the PT and the result is provided back to FT for construction 
of the Registration message. In the same manner authentication verification is performed in the PT upon provision of 
parts of the receipt by the FT Reply message. 

NOTE 2: The IP handled IP mobility authentication may be seen as moving the Authentication module, which 
normally will be a part of the FT RFC 3344 [17] protocol software, from the FT to the PT and 
standardizing the exchange between the FT's RFC 3344 [17] protocol and the PT's Authentication 
module. 

In this regard, all PPs that claim support of this clause shall support the requirements for IP mobility authentication 
calculation as specified in RFC 3344 [17] and the authentication algorithm as specified in RFC 2104 [24]. 

In regard to the requirements of this clause the IP roaming registration procedure shall be mapped to DECT Location 
registration and possibly DECT location update procedures as defined in GAP [13] with the modification specified in 
this clause. 

The user shall be provided with the capability to request IP mobility registration. Optionally a roaming PT may prompt 
the user to start the registration upon entering an IP mobility allowed area. Automatic registration may be implemented 
as well allowing for the PT to start registration as soon as it recognizes an area in which the IP mobility for this PT is 
allowed (Roaming RFPI is available and matches the one transmitted by the FT). 

NOTE 3: The provision of roaming security key for this procedure is optional, although the implementers should 
consider provision of encryption on the DECT air interface in any case (see GAP [13]) which could not 
be otherwise ensured as the visiting PT will not have a standard DECT subscription. 

The PT shall initiate an attach (roaming registration) procedure using the GAP Location registration procedure as 
defined in [13] providing at least its netmask address and its SPI, and, optionally its IP home-address and/or HA 
address. If Home address is not provided the User shall provide its User name in which case the FT shall follow the 
requirements specified in RFC 3344 [17] and RFC 2794 [25] for the construction of the Registration message. If HA 
address has not been provided the FT shall perform HA address discovery as specified in RFC 3344 [17]. Mobile IP 
bindings properties may be provided as well (see DECT IP Mobility Signature (DIMS) table earlier). 

Having obtained the provided information, the FT shall construct an IP mobility Registration message. The value of the 
Identification field shall be calculated by the FT - the timestamps method shall be used (see RFC 3344 [17]). The FT 
shall take into account that the calculation of the Authenticator value will consume some time therefore a time tolerance 
value shall be added to the actual timestamp relevant to the construction of the message. Addition of 2 sec is suggested. 
The FT shall send the message part over which the Authenticator shall be computed to the PT. The FT shall use the 
«IWU-TO-IWU» information element if necessary segmented in one or more {MM-IWUj messages. 

In figure 6 an example of a Registration message is shown. It is assumed that the PT has not provided Home Address 
and has provided Username therefore the MN-NAI extension is included. The relevant for authentication part is 
highlighted with colour and this is the data the FT shall send to the PT for authentication. 
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Table 4: Registration request message 



1 2 3 4 5 6 7 



01234567 01234567 



Type = 1 



D 



M 



Lifetime 



Home Address = 0.0.0.0 



Home Agent 



Care-off address 



Identification 



Type = 131 



Lengtii 



MN-NAI 



Type = 32 



Lengtii 



Security Parameter Index (SPI) 



SRI (cont..) 



MN-HA Authenticator (variable length) 



Optional Non-Auth Extensions for FA 



Optional MN-FA Authentication Extension. 



Having received the registration data the PT shall provide it as input, together with the relevant parameters from the 
Mobility Security Association to the authentication algorithm (HMAC-MD5 as specified in RFC 2104 [24]) and 
compute a 128-bit "message digest" of the provided data. If the SPI was not known to the FT before calculating the 
result the PT shall add it to the received information from the FT. 

The PT shall communicate back to the FT the result, i.e. the Authenticator value. The PT shall use the 
«IWU-TO-IWU» information element if necessary segmented in one or more {MM-IWU} messages. If the SPI was 
not known to the FT before calculating the result the PT shall provide the SPI to the FT. To reduce the exchange PT is 
not required to send back the whole Registration message. 

Finally the FT shall complete the Registration message and send it to the FA. 

After a successful Reply message is received the FT shall provide the Message part over which the HA has performed 
authentication calculation to PT. PT shall calculate Authenticator and return it to the FT. FT shall compare the received 
Authenticator and the one included into the Reply to verify the authenticity of the Reply. For this exchange again the 
«IWU-TO-IWU» lEs and the {MM-IWU} messages shall be used. 

If the completion of the procedures on the IP side is taking time longer than the time allowed for the completion of the 
DECT Location registration procedure the VFT shall used the {MM-NOTIFY} to restart the running at the PT timer 
associated with the attach procedure. 

Figure 6 shows an example of a complete PP IP roaming registration procedure. It assumes that: Roaming has been 
enabled at the FT (i.e. Roaming RFPI is available at the FT and at the PT). Compare to the case in the previous clause 
here there is no need for DECT authentication and ciphering. 
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PT1 



VFT 



<Roami nq Nv 

allowedlYesy LOCAT&REQ UEST 



(nelmask, user name, SPI) 



Computes the 
Autenticator 



Computes the 
Autenticator 



Computes the 
Registration message 
MM-IWU (authenttatioii'naTar 



MM-IWU (Authenticator) 



Completes the 
Registration message 



MM-IWU (authenttation data) 



MM-IWU (Authenticator) 



LOCAIE-ACCEPT 



< 



HA address 
discovery 



FA 



RegistratJon HA (NAI) , 



[RELAY] Replay 



HA 



[RELAY] Registration HA 



Replay (MNHome Address) 



Authenticators 
Equal=Yes 



> 



Figure 6: Successful PP mobile IP roaming registration (PT auth) 

The DECT message/information elements support required in addition to tlie requirements of GAP is indicated into 
clause 7.2.1.2.5. 



7.2.1.2.5 



Message/Information elements specification 



For the content of messages/information elements the requirements specified in EN 300 444 GAP [13] and/or in 
EN 300 175-5 [5] whenever relevant apply. For the structure of the «IWU-TO-IWU» information element the 
requirements in EN 300 175-5 [5] and annex A of the present document apply. This clause lists only the 
differences/additions. 

As a general rule if the inclusion of the «IWU-TO-IWU» in a message will result in message being longer than 
63 octets, the «IWU-TO-IWU» shall be segmented and provided in one or more additional {MM-IWU} messages. 
Consequently for the messages that carry the «IWU-TO-IWU» information element in addition to any mandatory 
information element the following basic structure shall apply. 

Table 5: Values used within an IP mobility MM message 



Information element 


Field within the information 
element 


Standard values within the 
field/information element 


Normative 
action/comment 


«Segmented lnfo» 






See note 




<Segmented element type> 


1110111 


«IWU-TO-IWU» 


«IWU-TO-IWU» 




All 




NOTE: Mandatory if the message will exceed 63 octets or winen carrying the last segment from a segmented 
«IWU-TO-IWU». 
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Table 6 specifies the structure and content of the «IWU-TO-IWU» information element in regard to IP mobility. 
Which and when a filed shall be included is indicated into the clauses that describe the procedures. 

Table 6: «IWU-TO-IWU» <Action> field 



Field 


Sub-field 


Value 


Comment 


S/R 




1 




Protocol Discriminator 




100100 


DECT access to IP networks 


Action 


Ext 


1 


Multi octet extension 


Value 


1000001 


IP Mobility: DIMS 


1000110 


IP Mobility: Authentication Payload 


1000100 


IP Mobility: Authenticator 


Body 


All 


All 


The content of this field depends on the settings 
of the Action Value and is described 
in tables 7 to 9. 



Table 7: «IWU-TO-IWU» <Action> field = "Authentication payload" 



Field 


Sub-field 


Value 


Comment 


S/R 




1 




Protocol Discriminator 




100100 


DECT access to IP networks 


Action 


Ext 


1 


Multi octet extension 


Value 


1000110 


IP Mobility: Authentication Payload 


Body 


Auth Payload 


All 


See note 


NOTE: RFC 3344 [1 7] specifies the part of the Registration/Reply messages over which Authentication is calculated 
and this shall be included here - the format shall be preserved. 



Table 8: «IWU-TO-IWU» <Action> field = "Authenticator" 



Field 


Sub-field 


Value 


Comment 


S/R 




1 




Protocol Discriminator 




100100 


DECT access to IP networks 


Action 


Ext 


1 


Multi octet extension 


Value 


1000100 


IP Mobility: Authenticator 


Body 


Authenticator 


All 


See note 


NOTE: RFC 3344 [1 7] specifies how the value of the Authenticator field is calculated - the format shall be 
preserved. 
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Table 9: «IWU-TO-IWU» <Action> field = "DIMS" 



Field 


Sub-field 


Value 


Comment 


S/R 




1 




Protocol 
Discriminator 




100100 


DECT access to IP networks 


Action 


Ext 


1 


Multi octet extension 


Value 


1000001 


IP Mobility: DIMS 


Body 


Fields_presence_indicator.ext 


1 


Multi octet extension - last 





Multi octet extension - more 


Fields_presence_indicator. value 


xxxxxxx 


Identifies which field is present in the rest 
of the Body. A bit set to "1" shall be 
understood as "field present" 


xxxxxxl 


Mobile IP bindings properties. Settings 


xxxxxlx 


Mobile IP bindings properties. Lifetime 


XXXXl XX 


Home Address 


XXX 1 XXX 


Care-off address 


xxixxxx 


Home Agent sets 


xlxxxxx 


Foreign Agent sets 


1 xxxxxx 


Not assigned yet 


IVIobile IP bindings properties. Settings 


All 


1 octet setting according to |S|B|D|M|G|r| 
T|x| defined in RFC 3344 [17] 


Mobile IP bindings properties. Lifetime 


All 


2 octets as defined in RFC 3344 [17] 


Home Address 




4 octets 


Care-off address 




4 octets 


Home Agent set fields indicator.ext 


1 


One Home set 





More Home sets 


Home Agent set fields indicator.value 


xxxxxxx 


Identifies which field is present in the 
Home set. A bit set to "1 " shall be 
understood as "field present" 


Netmask 


All 


4 octets 


Agent address 


All 


4 octets 


Security Parameter Index (SPI) MN-HA 


>255 


4 octets 


MSA.Auth algorithm+Reply protection 


0001 0001 


Auth. algorithm HMAC-MD5; Reply 
protection Timestamps 


0001 0010 


HMAC-MD5; Nonces (optional) 


0010 0001 


Keyed MD5; Timestamps (optional) 


0010 0010 


Keyed MD5; Nonces (optional) 


MSA. Secret Authentication Key. Length 


All 


Number of bits (at least 128 bits long keys 
shall be supported) 


MSA.Secret Authentication Key.Value 


All 




Username. Length 


1 to 255 
inclusive 


Number of octets 


Username. Value 


All 


IA5 characters (maximum 255 characters 
long) 


Foreign Agent Set fields indicator.ext 


1 


One Foreign set 





More Foreign sets 


Foreign Agent Set fields indicator.value 


xxxxxxx 


Identifies which field is present in the 
Foreign set. A bit set to "1" shall be 
understood as "field present" 


Netmask.Value 


All 


4 octets 


Agent address 


All 


4 octets 


Security Parameter Index (SPI) MN-HA 


>255 


4 octets 


MSA.Auth algorithm-hReply protection 


All 


See same field for Home agent set 


MSA.Secret Authentication Key. Length 


All 


Number of bits (at least 128 bits long keys 
shall be supported) 


MSA.Secret Authentication Key.Value 


All 




Username.Length 


1 to 255 
inclusive 


Number of octets 


Username. Value 


All 


IA5 characters 
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7.2.1.3 FP IP roaming IPv4 

A User may move (roam with) its entire DECT system which may include one FP and a number of PPs from one IP 
access point to another. The DECT system may comprises one or more DECT MN if multiple IP home addresses were 
assigned and different associations between the FT and different PTs were given different IP addresses. 

In such a case it is the responsibility of the FT to obtain care-off addresses and register all DECT MN at the new access 
as from the point of the PTs no change will occur. After obtaining all necessary information the FT shall update the 
PTs' DIMS as described in the previous clause. 

7.2.1 .4 Roaming without IP mobility (IPv4 and IPv6) 

This clause describes an alternative method of providing PP mobility between different FPs connected to IP networks 
without relying upon IP mobility protocols being implemented on the network. It is based on the assumption that when 
PP moves it does not take the assigned Home IP address. The address is kept with the FT and since the FP does not 
move it is always accessible on the assigned (home) IP address. 

7.2.1.4.1 General IP issues 

When a FP is connected to an IP network it will obtain one or more IP addresses. The User may associate these IP 
addresses with one or another PP subscribed to the FP. From this moment on the particular FP becomes the Home FP 
(HFP) for this PP. A home FP shall maintain a Home Data Base for each of the PPs it has associated IP addresses. 

When a PP moves to another FP its IP address shall remain associated with the Home FP. At the new Visited FP (VFP) 
the visiting PT shall provide its home address and as soon as a new IP address is obtained at the new location this shall 
be associated with the visiting PP and the VET shall communicate to the HFT (over IP) the new address of the PP. 

After the new address of the PP has become known to the HFT the communication handling depends on the 
implementation. Two alternatives are identified: 

• Tunnelling: the Home FP shall act as a router (or a Home Agent) for communication to and from the PP, 
i.e. whenever data arrives with destination address the IP address associated with the PP, the Home FT shall 
route (tunnel) the data to the new address of the PP; likewise, when the PP wants to send out data the Visited 
FT shall send it (reverse tunnel) to the Home FT which in turn shall send it to the right destination (the original 
home IP address shall be used as source address). Both HFT and VET shall support tunnelling datagrams using 
IP in IP encapsulation (RFC 2003 [26]). 

• SIP mix: the Home FT shall act as a mixer for a SIP based 3PTY conference like call. Although handled as a 
SIP 3pty call this call will have only 2 parties and 2 call legs, i.e. the VET (the Party at the PP visited location) 
and the Called/Calling Party (the Party which was called or initiated the call), and consequently, a call leg 
from the VET (PP's visited location) to the HFT and from the HFT to the location of the Called/Calling Party. 

DECT specific signalling information (see the clause 7.2.1.4.2) exchanged between the VET and the HFT shall be 
included into the body of internet messages formatted according to the RFC 2045 [28] and RFC 2046 [29] MIME 
specification using Content-type: application/octet-stream and Content-Transfer-Encoding: binary; the "Subject" field 
shall provide in text the DECT message type code for the message carried in. For example if the included message is 
the I AUTHENTICATE-REQUESTj, the "Subject" field shall indicate "01000000" as specified in clause 7.4 of 
EN 300 175-5 [5]. The messages shall be transmitted in the case of tunnelling using the SMTP as specified in 
RFC 2821 [27] and in the SIP messages Message body for the case of SIP mix (see RFC 3261 [18]). 

7.2.1 .4.2 General DECT issues 

From DECT point of view roaming between different FPs will require a solution in regard to subscription and security 
which allows the PT to attach to a Visited FT. 

To avoid a FT to be overloaded with undesirable requests for roaming from PTs and visa versa PTs getting into dead 
circles by trying to access FTs that does not offer the roaming service, each FT and PT that claims support to the present 
document shall comply to the requirements defined in clause 7.2.1.2.2 in regard to setting up of a Roaming RFPI or 
alternatively, DECT business or Public networks can use the EN 300 824 [14], DECT CAP profile. 

This clause specifies requirements only related to the communication between the VET and the HFT. 



£75/ 



28 ETSI TS 1 02 265 V1 .2.1 (2004-1 0) 

7.2.1.4.3 The tunnelling method 

For terminals that support the tunnelling method the requirements specified in this clause apply. 

After a PT establishes that it is allowed to roam to a particular FT it shall attempt roaming registration. In such a case 
the PT, VFT and HFT shall comply with the following: 

• PP tries to attach to a VFT indicating Roaming registration and providing the HFT address - sends 
{LOCATE-REQUEST}. 

• VFT stores temporarily the HFT address, adds its own address, constructs an internet message incorporates the 
{LOCATE-REQUEST} into the body and sends the message to the HFT. 

• HFT extracts the DECT messages from the Internet message, stores temporarily the VFT address and 
Authenticates the PP by constructing a { AUTH-REQ}, incorporating it in an Internet message and sending the 
message to the VFT. 

• VFT extracts the { AUTH-REQ } and sends it to the PT. 

• PT sends {AUTH-REPLY} to VFT. 

• VFT constructs an internet message incorporates the {AUTH-REPLY} into the body and sends the message to 
the HFT. 

• If authentication is successful the HFT stores PT bindings and sends back the {LOCATE- ACCEPT}. 

• VFT extracts the { LOC ATE-ACCEPT } , stores PT bindings, and sends it to the PT. 

An example of a message carrying the { AUTHENTIC ATE-REQUEST} message is provided in table 10. 

Table 10: AUTH-REQUEST example 



From: main@etsi.orq 


To: einstein@etsi.org 


Subject: 01 000000 


Date: Fri, 25 Jul 2003 09:55:06 -0600 


IVIIIVIE-Version: 1.0 


Content-type: application/octet-stream 


Content-Transfer-Encoding: binary 


05 40 0a 03 01 10 10 Oc 08 90 18 03 a1 83 01 70 0a 



After a PT has registered to a particular FT normal operation can resume, e.g. outgoing/incoming calls can be handled. 
In such a case the PT, VFT and HFT shall comply with the following: 

Outgoing Calls Tunnelling 

• PT Provides Calling party To address indicating "IP Mobility: Call establishment". VFT shall construct an 
internet message, include the CC-SETUP in the message body and forward the message to the HFT. Mapping 
between DECT signalling messages and IP shall be made in the HFT. Any run in parallel DECT procedures 
shall be made between the HFT and VPT and the transport mechanism as described above shall be used 
(SMTP and MIME messages). 

Incoming calls Tunnelling 

• On receipt of a call dedicated to the PT, HFT shall initiate a DECT incoming call as described GAP. DECT 
messages shall be transferred to the VFT incorporated into Internet message as describe above. The Calling 
party number shall be sent using IWU-TO-IWU information element. 



• 



The VFT shall recover the DECT message and received from the HFT and send them to the PT, and shall 
incorporate DECT messages received from the VPT into Internet message as describe above and send them to 
the HFT. 
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7.2.1.4.4 The SIP mix method 

For terminals that support the SIP mix method the requirements specified in this clause apply. 

After a PT establishes that it is allowed to roam to a particular FT it shall attempt roaming registration. In such a case 
the PT, VFT and HFT shall comply with the following: 

Registration: in this case the same exchange of DECT messages as in the Case of the Tunnelling method shall be used. 
The method for transport, however should be based on establishing of a SIP session between the VFT and the HFT and 
carrying the DECT messages as Message bodies into the relevant SIP messages (Messages specified in SIP extensions 
may be used as well if supported by the SIP protocols at both sides): 

• { LOCATE-REQUEST } into the { INVITE } . 

• { AUTH-REQUEST } into the { 200 OK } . 

• { AUTH-REPLY } into the { ACK } . 

• {LOCATE- ACCEPT} into the {BYE}. 
Outgoing/Incoming calls: 

• Te rules for SIP conference sessions shall apply (RFC 3261 [18]). 



7.2.1.4.5 



DECT elements of messages/procedures 



DECT procedures relevant for this clause shall be implemented as described in GAP, EN 300 444 [13], or if not 
included there as described in DECT Common Interface (CI), EN 300 175-5 [5], Network (NWK) layer. Modifications, 
additions specified in this clause apply as well. 

Specific IP related information shall be included into IWU-TO-IWU information element. If necessary the 
IWU-TO-IWU shall be segmented to avoid messages exceeding 63 octets of length. 

Table 11: «IWU-TO-IWU» Action field = Registration/Call establishment 



Field 


Sub-field 


Value 


Comment 


S/R 




1 




Protocol 
Discriminator 




100100 


DECT access to IP networks 


Action 


Ext 


1 


Multi octet extension 


Value 


1001000 


IP IVIobility: Registration 


Body 




1001001 


IP IVIobility: Call establishment 


Fields_presence_indicator.ext 


1 


Multi octet extension - last 





Multi octet extension - more 


Fields_presence_indicator. value 


xxxxxxx 


Identifies which field is present in the rest 
of the Body. A bit set to "1" shall be 
understood as "field present" 


XXXXl XX 


To address 


XXXl XXX 


From address 


To 


All 


4 octets 


From 


All 


4 octets 



Due to the fact that the transmission of DECT messages over the IP may take longer time, the use of the {CC-NOTIFY} 
and {MM -NOTIFY} is required to avoid timing out at the initiating side. The VFT shall be responsible for sending the 
messages to the VPT and the HFT IWU shall take care of it at the HFT side. 



7.2.1.5 



User roaming IP roaming IPv4 



The User roaming is a feature that allows a User to be accessible on its Home address as defined by RFC 3344 [17] 
when the user moves from one DECT PP terminal to another DECT PP terminal. 
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For the provision of this feature: 

The user shall be capable of carrying on external media all mandatory IP mobility parameters. 



• 



• 



The DECT terminals shall support setting up of multiple user profiles allowing for a visiting user to configure 
its own MN profile on a visited terminal. 

The support of multiple user profiles adds to the concept of DECT MN defined in the previous clauses the possibility 
that one and the same tandem of a PP and FP may represent more than one DECT mobile nodes. 

For the provision of multiple user profiles the following requirements apply: 

• A DECT PP shall be capable of establishing and storing more than one DIMS as defined in clause 7.2.1 .2.2 
distinguishable by the Username. All actions related to IP mobility registration and call handling shall be 
distinguished by Username/DIMS. This may require either pre-setting of the PP in user X mode, or upon user 
request for action the user X shall provide her username. 

• A DECT FP shall be capable of establishing different user records based on the PP's IPUI and the Username. 
All actions related to IP mobility registration and call handling shall be distinguished by IPUI/Username. For 
incoming actions, e.g. incoming calls provision at the Portable terminal of an indication for which user the call 
is related is required. 

• In regard to IP mobility the requirements as stated in all relevant previous clauses parts of clause 7.2. 1 shall 
apply, e.g. in addition to the requirements specific for User roaming a designer needs to implement the 
requirements for PP IP Mobility for example. 

For User Identification the User name shall always be included: 

• For Registration into the {LOCATE-REQUEST} message even if Home Address is provided 
(see clause 7.2.1.2.3). 

• For Call handling in a «IWU-TO-IWU» information element indicating "IP Mobility: DIMS" and providing 
the User name (see clause 7.2.1.2.5). The «IWU-TO-IWU» shall be included into the 

{CC-SETUP} message. 

7.2.2 Handover 

IP handover is not currently specified in the IETF - IP roaming is. An IP handover includes IP roaming and 
consequently all IP roaming requirements in the case of IPv4 as specified in RFC 3344 [17] shall apply (the case of 
IPv6 is left for further study). Compliance with the Registration procedure defined for the IPv4 Mobility will result in 
unpredictable time interruption and will make DECT seamless handover impossible. 

The IPv4 Roaming without IP Mobility feature specified in clause 7.2.1.4, however, does not require such registration 
and hence can provide handover capabilities to terminals that support it. The requirements needed for the provision of 
external handover in addition to the requirements specified in clause 7.2.1.4 are described in this clause. 

7.2.2.1 Basic requirements 

DECT External handover is currently defined in the EN 300 824 CAP [14] and EN 300 175-5 [5], Network (NWK) 
layer. The DECT CAP standard does not specify the backbone network that interconnects the separate DECT base 
stations (FTs) or/and DECT sub-networks. 

There are two basic pre-requisites defined in CAP for the correct external handover operation: 

• The provision of FT identities that allow a PT to handover from one FT to another without the need to register 
at the time of handover. Such Identity is assumed to be provided and set up by the network operator. 

• The provision, by the FT to which the PT is locked, of handover candidates from which the PT may choose. 

For the case of large systems, e.g. CTM or PBXs, a centralized provision and management of the identities and access 
rights is feasible and such capabilities are usually foreseen and provided by the manufacturer. Therefore, for such 
DECT systems the requirements specified in CAP [14] or other suitable DECT standards still can apply. 
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For smaller, a kind of a self-made plug-and-play, DECT systems based on an IP network backbone and e.g. a number of 
DECT residential FPs, an easier manageable solution is desirable. The present document specifies two alternatives. 

• Alternative one (1) is based on the requirements specified in clause 7.2.1.2.2 and mandates a manual, set by 
the user, SARI which shall solve both problems: provision of access rights and handover candidate indication. 
The combination of a common Roaming ARI plus the indication of "External Handover allowed" broadcasted 
by the FT shall provide a PT with the bases for taking of a decision to attempt external handover to a FT. This 
solution avoids the use of Handover Candidate/Reference procedures as specified in CAP. 

• Alternative two (2) is based on automatic assignment of a Roaming ARI and is suitable for FTs that are 
connected to one and the same IP network. The procedure is defined in clause 7.2.2.2. This solution provides 
as an option the usage of Handover Candidate/Reference procedures as specified in CAP. 

After a PT has established that an external handover to a particular FT is allowed it shall initiate an External Handover 
call setup procedure as defined in clause 7.2.2.3. 

7.2.2.2 Automatic assignment of a external handover related identities 

Upon connection to the IP NWK a FT shall listen for T_roaming time whether a Roaming RFPI is being broadcasted on 
the net. The FT shall repeat the procedure up to N_roaming times if no Roaming RFPI broadcast has been detected. 

If no Roaming RFPI is received the FT shall allocate a Roaming RFPI for this network and shall start periodically 
broadcasting it on the IP network for every FT that may connect to the same network. 

For the allocation of a Roaming RFPI the FT shall use the procedures defined in clause 7.2. 1.2.2 with the following 
modification. If the FT's PARI contains ARI of class A, the FT should request the PT to assist in the allocation of the 
Roaming RFPI FPN number. In this case the PT shall listen for a Roaming RFPI possibly transmitted by FTs connected 
to another closely allocated IP network, shall then determine the FPN number and send it back to the FT. If the FT's 
PARI contains ARI not of class A it shall use its own RFPI for the allocation of the Roaming RFPI. The FT initiated 
parameter retrieval procedure shall be used. The «Info Type» information element in the {MM-INFO-SUGGEST} 
message shall be set to "Identity allocation". At the PT side the procedure defined in clause 7.2.1.2.2 shall apply. 

For the broadcast on the IP network the FT shall use the {MM-INFO-SUGGEST} message included into the body of 
internet messages formatted according to the RFC 2045 [28] and RFC 2046 [29] MIME specification using 
Content-type: application/octet-stream and Content-Transfer-Encoding: binary and "Subject" field set to "01010010", 
i.e. the message type code for {MM-INFO-SUGGEST}. The {MM-INFO-SUGGEST} message shall contain a 
«Info type» indicating "External handover parameters" and a «Network parameter» information element 
indicating Handover reference, e.g. "Handover reference, private network" and providing the Roaming ARI. 

If a Roaming RFPI is received the FT shall accept it and shall start broadcasting it on the DECT air interface as a SARI 
(see clause 7.2.1.2.2) together with the indication "External Handover Supported". 

7.2.2.3 External handover call setup 

For the External Handover call establishment the requirements as specified in CAP [14], clauses 9.1.4 and 9.1.5 shall 
apply with the following modifications. 

The support of External handover candidates related procedures/requirements is optional. The choice of FT suitable for 
external handover shall be based on the common knowledge of the Roaming ARI broadcasted. 

For the external handover call setup in addition to indicating "External handover" into the «Basic Service» 
information element included into the {CC-SETUP} message, the PT shall provide its current IP address, i.e. the 
address on which the PT is engaged in the call which the PT attempts to handover. The IWU-TO-IWU information 
element shall be used indicating "IP Mobility: Call establishment" and the address shall be provided into the "To" field 
of the <Body>. 
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Table 12: «IWU-TO-IWU» Action field = Registration/Call establishment 



Field 


Sub-field 


Value 


Comment 


S/R 




1 




Protocol 
Discriminator 




100100 


DECT access to IP networks 


Action 


Ext 


1 


Multi octet extension 


Value 


1001000 


IP IVIobility: Registration 


Body 




1001001 


IP Mobility: Call establishment 


Fields_presence_indicator.ext 


1 


Multi octet extension - last 





Multi octet extension - more 


Fields_presence_indicator. value 


xxxxxxx 


Identifies which field is present in the rest 
of the Body. A bit set to "1" shall be 
understood as "field present" 


XXXXl XX 


To address 


To 


All 


4 octets 



Having the address of the FT that is currently handling the call (HFT) the VFT should proceed depending on the 
implementation of the IP network: 

• If SIP is supported on the NWK, the VFT may attempt to establish a "3 party conference" session with the 
HFT which should mix the current call leg and the new call leg. A DECT LOCATE-REQUEST message 
providing the PT's identity should be included into the INVITE message body to be used as indication that this 
is an attempt of external handover. The HFT may perform authentication towards the VFT-PT to ensure that 
the PT is indeed the one engaged in the call. 

• If SIP is not supported, the VFT should incorporate the received from the PT {CC-SETUP} message into the 
body of an internet message formatted according to the RFC 2045 [28] and RFC 2046 [29] MIME 
specification as specified in clause 7.2.1.4 and send it to the HFT. Upon reception of the message the HFT 
should attempt establishing of a VoIP call to the VFT and if successful should connect the two paths. The HFT 
may perform authentication towards the VFT-PT to ensure that the PT is indeed the one engaged in the call. 

7.2.2.4 FP synchronization over the IP network 

For handover purposes synchronization between FTs may be desirable. 

NOTE: There may be PTs that support handover between non synchronized FTs. However, due to the fact that 
such an implementation requires support of two reference clocks there are not many terminals on the 
market supporting it. Furthermore, handover between unsynchronized FTs reduces the overall DECT 
capacity. 

In the IP world time synchronization across network servers, routers and network devices with accuracy to the order of 
a microseconds may be achieved using the well-established Network Time Protocol (NTP, RFC 1305 [21]). Most users 
of the Internet NTP synchronization use a relatively big and complex software package which may not be appropriate 
for all applications. The Simple Network Time Protocol (SNTP, RFC 2030 [20]) has been designed to target wide 
variety of "simpler" applications, however, SNTP provide accuracy only in the order of milliseconds. 

The DECT specification requires that the difference between reference timers of synchronized RFPs shall be less than 
4 microseconds. Consequently if a system would like to provide DECT base stations synchronization over the IP it shall 
implement the NTP [21]. 

If the cost of such implementation is not feasible DECT base station synchronization over separate wire or the DECT 
air interface may be more applicable. The implementation of such solutions is out of the scope of the present document. 
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7.3 SIP interworking 
7.3.1 General 

This clause specifies the requirements in regard to the mapping between SIP and DECT relevant procedures and 

messages. 

The IP procedures, and, messages format and content mapped to DECT procedures/messages are based on the 
requirements found into the following IETF RFCs: 



RFC 3261 [18] 
RFC 2327 [19] 
RFC 2617 [22] 
RFC 2806 [23] 



"SIP: Session Initiation Protocol". 

"Session Description Protocol (SDP)". 

"HTTP Authentication: Basic and Digest Access Authentication". 

"URLs for Telephone Calls". 



DECT procedures/messages requirements are based on those specified in: 

DECT Common Interface (CI), EN 300 175-5 [5], Network (NWK) layer. 
DECT Generic Access Profile (GAP), EN 300 444 [13]. 
DECT Data Packet Radio Service (DPRS), EN 301 649 [16]. 
DECT Open Data Access Profile (ODAP), TS 102 342 [32]. 

SIP is an application-layer signalling protocol that can establish, modify, and terminate interactive multimedia sessions 
over IP between intelligent terminals with one or more participants. These sessions include Internet telephone calls, 
multimedia distribution, and multimedia conferences. It is a clear text client/server protocol using Uniform Resource 
Locators (URL) for addressing (in this sense having a lot in common with HyperText Transfer Protocol (HTTP)). 

SIP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible 
media types (users may move between endpoints, they may be addressable by multiple names, and they may 
communicate in several different media - sometimes simultaneously). SIP makes use of elements called proxy servers to 
help route requests to the user's current location, authenticate and authorize users for services, implement provider 
call-routing policies, and provide features to users. SIP also provides a registration function that allows users to upload 
their current locations for use by proxy servers. 

SIP runs on top of several different transport protocols enabling Internet endpoints called user agents (UA) to discover 
one another and to agree on a characterization of a session they would like to share. For locating prospective session 
participants, and for other functions, SIP enables the creation of an infrastructure of network hosts (called proxy 
servers) to which user agents can send registrations, invitations to sessions, and other requests. 

A user agent represents an end system. In the context of the present document a User Agent comprises a DECT FP and 
a DECT PP part and the UA activities may be provided either by the FP part (called FP-UA) or by the PP (called 
PP-UA). As a FP can serve a number of PPs, each tandem of the FP and a PP may, but need not, represent an 
independent UA, i.e. the FP may be engaged in a number of different UAs, whereas a PP may be engaged only in one 
UA at a time. 
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Figure 7: SIP elements reference model 
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Figure 8 shows a basic example of IP and DECT protocols' interaction model in a FT in the scope of the present 
document. The Ethernet protocol, towards the external NWK, is shown only as an example and other relevant IP 
protocols may be present. 
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Figure 8: Protocols relation reference architecture FT 

Generally speaking, a DECT PT may be seen as comprising: 

• A special signalling related application that uses the DECT protocol to interwork with the residing into the FT 
SIP and related protocols. This application represents an interface to the user, thereby allowing for the user to 
actively interact with the network, and is responsible for the provision to the FT of all user information and 
terminal's media capabilities that the FT, in turn, needs to successfully implement and perform the SIP and 
related protocols requirements. 

• One or more media applications capable of handling different media formats, e.g. voice, video, graphics, etc. 

During a single SIP session the user may utilize a number of different PPs each capable of handling different media, 
e.g. one voice capable PP and one PP acting as a camera, or, a single portable capable of handling more than one type of 
media streams, e.g. one voice capable PP with a camera. Currently the DECT protocol does not provide means of 
handling bearers carrying different type of higher layer U-plane channels during one and the same call, therefore SIP 
sessions that involve different types of media may require multiple DECT calls to handle each of them. For example a 
voice and camera capable PT will need a GAP voice call and a DPRS data call to the same FT which is involved in the 
SIP session handling the two media streams. In regard to handling different types of media all terminals complying to 
the present document shall obey the following general rules: 

• For provision of voice media a terminal (PT or FT) shall indicate GAP support and all call related DECT 
protocol proceedings shall be based on the requirements specified in the DECT Generic Access Profile (GAP), 
EN 300 444 [13] with any modification/addition specified in the present document. 

• For provision of voice media a terminal (PT or FT) shall, 

IF the terminals support high data rate transport THEN the terminal shall indicate DPRS support and all 
call related DECT protocol proceedings shall be based on the requirements specified in the DECT Data 
Packet Radio Service (DPRS), EN 301 649 [16] with any modification/addition specified the present 
document. 

IF the terminals support low data rate transport THEN, the terminal shall indicate ODAP support and all 
call related DECT protocol proceedings shall be based on the requirements specified in the DECT Open 
Data Access Profile (ODAP), TS 102 342 [32] with any modification/addition specified the present 
document. 
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The Procedures described in this clause are based on the exchange of SIP related information carried into one or a 
number of DECT «IWU-TO-IWU» information elements. Although other DECT information elements could have 
been used for different portions from the SIP messages content, the current approach has been chosen with the aim of 
facilitating the protocol implementation by separating and concentrating all relevant data into a single space. 
Furthermore the current approach requires a single information decoding/interpretation requirement: data shall be 
formatted/interpreted as specified in RFC 3261 [18]. Contrary to RFC 3261 [18] however the present document 
mandates usage of IA5 character set (see EN 300 175-5 [5], clause D.2.3) on DECT air which requires the DECT FT 
to make the conversion IA5/UTF-8 (the latter mandated for usage in SIP). 

In compliance to GAP the present document does not mandate the support of DECT messages of more than 63 octets 
length (see EN 300 444 [13], GAP, clause 6.9.3). SIP information is a character based which will inevitably result into 
longer DECT messages. Consequently, implementations that comply with the present document shall support DECT 
segmentation of information elements, i.e. whenever necessary the «IWU-TO-IWU» information element shall be 
segmented in a number of DECT messages. As a general rule in the case of a MM procedure the «IWU-TO-IWU» 
segments from the second segment on shall be carried in jMM-IWU} messages and in the case of the CC procedure 
into jIWU-INFO} messages. To allow sending/reception of jMM-IWU} messages after the last message of a MM 
procedure has been sent/received the MM entity shall indicate "partial release" in the NLR notification as specified in 
EN 300 175-5 [5], clause 14.2.7.2. 

7.3.2 Registration 
7.3.2.1 Procedure mapping 

All FTs that claim compliance to the present document shall implement the SIP Registration procedure as defined in 
RFC 3261 [18]. The SIP Registration procedures (RFC 3261 [18]) create explicitly bindings in a location service for a 
particular domain that associates an User Agent's (UA's) Address-Of-Record (AOR), i.e. a URI (Unified Resource 
Indicator), with one or more contact addresses. An AOR is a SIP or SIPS URI that points to a domain with a location 
service that can map the AOR to a contact address (another URI) where the user might be available. An AOR is 
frequently thought of as the "public address" of the user whereas a contact address is an address on which the user may 
be found at a particular moment of time. The AOR is normally given to the user from a service provider. In addition for 
security reasons a user name and password will normally be given to the user too. 

NOTE 1 : There are many ways by which the contents of a location service can be established. One way is 
administratively. These are out of the scope of the present document. 

SIP registration entails the UA sending a REGISTER request to a special type of UA known as a registrar which acts as 
the front end to the location service for a domain, reading and writing mappings based on the contents of REGISTER 
requests. This location service is then typically consulted by a proxy server that is responsible for routing requests for 
that domain. 

NOTE 2: The registrar and proxy server are logical roles that can be played by a single device in a network. 

SIP distinguishes a number of UA registration related procedures which for the purpose of the present document are 
grouped in three sets: 

• Adding/Modifying bindings including: Adding bindings. Setting the Expiration Interval of Contact Addresses, 
Setting Preferences among Contact Addresses and Removing Bindings. 

• Fetching Bindings. 

• Refreshing Bindings. 

The Adding/Modifying bindings procedures shall be mapped to the DECT Attach (Location registration) procedure as 
specified in GAP, EN 300 444 [13], DPRS EN 301 649 [16] or ODAP TS 102 342 [32] and modifications/additions 
specified in the present document. The fetching bindings shall be mapped to a Parameter retrieval procedure as 
specified in EN 300 175-5 [5] and modifications/additions specified in the present document. The Refreshing Bindings 
is not mapped to a DECT procedure. 

NOTE 3: It is possible that the manufacturer of a DECT FP offers some proprietary means at the FP for 

configuration of all necessary parameters allowing for the DECT FT to be fully in control and perform all 
necessary tasks in regard to SIP registration. Such implementation is out of the scope of the present 
document. 
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7.3.2.1.1 Adding/Modifying bindings 



FTs shall implement the SIP adding and modifying bindings registration procedures as defined in RFC 3261 [18]. This 
clause specifies requirements on the DECT air interface for provision of means to facilitate the FT's communication 
with the IP network. All SIP procedures falling in this group can be run separately or in combination and shall be 
started upon the User's request. 

Upon procedure initiation the user shall provide at least its AOR (<To> field of the REGISTER message) and the 
relevant authentication data (password, realm and user name). In addition the user may optionally provide contact 
details (<Contact> field of the REGISTER message), i.e. one or more contact addresses with associated parameters, 
e.g. preferences ("q" value in the <Contact> field) and expiration time ("expires" value in the <Contact> field). All 
information shall be provided via a suitable PP user interface (see notes 2 and 3). 

NOTE 1: SIP relevant fields are specified in RFC 3261 [18]. 

The minimum information provision required for support at the PT is the user's AOR, password, realm and user name. 
In this case the FT shall be capable of establishing the contact address in regard to the access point it is attached to and 
go for default contact details according to registrar administration polices. This minimum requirement does not allow 
the user to be able to choose contacts and details, to request more than one binding registration, nor to register bindings 
for a third party. For the provision of these services the user (and the PT) should be capable of supplying additional 
information: 

• A contact address for registering a binding. 

• A contact address AND contact parameters ("q" and "expire") for registering a binding with preferred 
parameters, as well as, removing a binding (expiration = 0) and removing all bindings (Contact = *). 

• More contact addresses and parameters for registering more than one binding at a time. 

• Differentiation between addresses provided for the "To" and "From" field for registering a third party. 

Using the submitted by the user information the PT shall start a DECT Attach procedure providing the information in 
the «IWU-TO-IWU» information element of a {LOCATE-REQUESTj message. The PT is not required to store any 
of the provided information. 4. If the information to be included into the «IWU-TO-IWU» information element will 
resuh in a {LOCATE-REQUESTj message longer than 63 octets, the «IWU-TO-IWU» shall be segmented and 
segments shall be included in one or more { MM-IWU } messages being sent after the {LOCATE-REQUESTj message 
carrying the first segment. PT shall restart timer <MM_locate.l> after sending every { MM-IWU j message. 

Upon receipt of the {LOCATE-REQUESTj message the FT shall check for the presence of a «IWU-TO-IWU» and 
possibly a «Segmented Info» information elements. If «IWU-TO-IWU» has been segmented FT shall await 
reception of one ore more { MM-IWU j messages and attempt to re-assemble the complete information. When the 
information has been re-assembled the FT shall examine it, shall store it in a user record distinguished by the PT's IPUI 
and the user's authorization data, and shall proceed with the desired procedure at the IP side depending on the content of 
the «IWU-TO-IWU» i.e. a SIP Registration related procedure. 

If the procedure is successful at the FT-IP side the FT shall store the agreed details and send back to the PT a 
{ LOCATE- ACCEPT j message. Any difference between the provided by the user and the approved by the registrar 
information shall be communicated to the user in the «IWU-TO-IWU» information element. If the user requested 
Adding bindings and did not provide a <Contact> into the request, the associated with the registration contact shall be 
provided by the FT into the { LOCATE- ACCEPT j message for user information. In the SIP 200 OK message normally 
all existing bindings of the user will be provided, including such made previously; these bindings may but need not be 
provided to the user at this moment and may but need not be stored in the user record in the FT (see the procedure for 
Fetching bindings later on in this clause). 

If the information to be included into the «IWU-TO-IWU» information element will result in a 
{ LOC ATE- ACCEPT j messages longer than 63 octets, the «IWU-TO-IWU» shall be segmented and segments shall 
be included in one or more {MM-IWU j messages being sent after the { LOC ATE- ACCEPT j message carrying the first 
segment. The MM entity shall use "partial release" to maintain the link open for these messages. 
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NOTE 2: The implementation of the interface and dialog with the user (possibly a combination of keypad and 

display) for providing the required information is left to the manufacturer. User may be provided with the 
opportunity of inputting the URI manually or selecting it from some sort of address book. User may be 
allowed to provide only partial information which will later on be correctly formatted by the PT before 
providing it to the FT, e.g. the user needs not enter a complete URI, but rather a string of digits or letters 
(for example, "sbaev" for sip: sbaev@etsi.org). Furthermore, the user needs not be required to enter some 
field formatting characters, e.g. "<". It is at the discretion of the PT-UA to choose how to interpret this 
input and provide unambiguous data to the FT-UA (e.g. sip and sips need to be distinguished, etc.). 

NOTE 3: In the case of the Setting the Expiration Interval of Contact Addresses SIP provides two ways in which a 
client can suggest an expiration interval for a binding: through an Expires header field or an "expires" 
Contact header parameter. The latter allows expiration intervals to be suggested on a per-binding basis 
when more than one binding is given in a single REGISTER request, whereas the former suggests an 
expiration interval for all Contact header field values that do not contain the "expires" parameter. The 
present document specifies that expiration, when provided by the user, will be provided per binding. 

NOTE 4: It is assumed that a Location registration procedure may also take place under circumstances out of the 
scope of the present document where it may be regarded as a location registration in the normal DECT 
meaning and not as a SIP Registration. A manufacturer may for example chose to pre-register a PP with a 
FP and sale them together. At such point of time no SIP information will be available. In such cases no 
«IWU-TO-IWU» information element indicating a SIP action will be present in the 
{LOCATE-REQUEST} message. 

NOTE 5: The maintenance of a User record at the FT side is mandated to allow faster SIP handling and reduced 
DECT on-air traffic. 

If the completion of the procedure on the IP side takes longer time that the time guarding the Attach procedure duration 
in the PT the FT shall restart the PT timer sending a { MM-NOTIFY } message. 

Upon receiving the { LOCATE- ACCEPT } message the PT shall assess the presence and content of the 
«IWU-TO-IWU» and possibly the «Segmented info» information elements. If «Segmented info» is present the 
PT MM entity shall indicate "partial release" to the LCE to maintain the link open for the following up {MM-IWU} 
messages. After the complete information has been re-assembled the PT shall examine it and inform the user for any 
details. 

NOTE 6: The presentation of the information to the user is left to the manufacturer's choice. 

For security reasons if a SIP registration procedure has been requested the PT shall first cipher the link. The 
requirements for Cipher switching initiated by PT procedure as specified in GAP, EN 300 444 [13], clause 8.34 apply. 
Figure 9 provides an example of messages flow of a SIP Registration procedure. 



PT1 


CIPHER-SUGGEST 


r 


n 


REGISTER 






User 

requests 

registratioT 


^ 




registrar 
(proxy 1) 






^ 






M 


CIPHER-REQUEST 


W 














ciphered 


1 cipheied | 




LOCAIE-RBQUEST 








^ 










MM-IWU 








K 






M 


LOCAIE-ACCEPT 


r 






^ 


200OK 


w 
















^ MM-IWU 






J . 






IMVIP-ID- ASSIGN- AC K ^ 










w 






^1 


^1 


^H 




^1 



Figure 9: Successful SIP registration 
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If a SIP Registration related procedure fails the FT shall reject the Attach procedure providing the SIP response code 
word and optionally the code into the {LOCATE-REJECT} message if the reason for the failure could be attributed to 
the User's input, e.g. misspelled address. The user shall be informed, e.g. the problem should be displayed. The user 
may re-initiate the procedure. If the information to be included into the «IWU-TO-IWU» information element will 
result in a {LOCATE-REJECT} messages longer than 63 octets, the «IWU-TO-IWU» shall be segmented and 
segments shall be included in one or more {MM-IWU} messages being sent after the {LOCATE-REJECT} message 
carrying the first segment. The MM entity shall use "partial release" to maintain the link open for these messages. 

In some cases the reason for failure at the SIP side may be attributed to technical problems not related to the user, 
e.g. timeout at the registrar due to delay on the IP network. If possible the FT shall try to solve the problem before 
completing the attach procedure and without engaging the PT and the user. If however this is not possible for the time 
required for response back to the PT, the FT shall reject the attach procedure providing the reason for the rejection. 
After rejecting the attach the FT may still try to register following the rules as specified in the SIP protocol 
RFC 3261 [18] and inform the user for the results. The user should be properly informed for such activities. If the user 
tries to register again when a registration procedure is still in progress at the FT-IP side, the FT shall examine the new 
{LOCATE-REQUEST} message and if there is no different address parameters provided shall continue with the 
on-going registration (new contact parameters shall be ignored). In any other case the FT should try to complete the 
ongoing procedure before taking any action. 

7.3.2.1.2 Fetching bindings 

The user shall be provided with the possibility to review its registration details. Upon procedure initiation the user shall 
provide the relevant authentication data (password, realm and user name). 

Using the submitted by the user information the PT shall start a DECT Parameter retrieval procedure providing the 
information in a {MM-INFO-REQUEST} message. If the information to be included into the «IWU-TO-IWU» 
information element will result in a {MM-INFO-REQUEST} messages longer than 63 octets, the «IWU-TO-IWU» 
shall be segmented and segments shall be included in one or more {MM-IWU} messages being sent after the 
{MM-INFO-REQUEST} message carrying the first segment. The PT shall restart timer <MM_info.l> after each 
{MM-IWU} message sent. 

Upon receipt of the request the FT shall examine the provided data and shall compare it with the data the FT has stored 
for that PT/user. If the data matches the FT shall provide full bindings details back into a {MM-INFO- ACCEPT} 
message or reject the request otherwise with a {MM-INFO-REJECT} message. The bindings details should be retrieved 
from the PT record maintained at the FT if FT maintains full bindings details, or otherwise the FT shall initiate SIP 
fetching bindings procedure towards the IP before sending the response. It is the responsibility of the FT to guarantee 
that up to date registration information is always available into the User's record. 

If the completion of the procedure on the IP side takes longer time that the time guarding the Parameter retrieval 
procedure duration in the PT the FT shall restart the PT timer sending a {MM-NOTIFY} message. 

If the information to be included into the «IWU-TO-IWU» information element will result in a 
{MM-INFO- ACCEPT/REJECT} messages longer than 63 octets, the «IWU-TO-IWU» shall be segmented and 
segments shall be included in one or more {MM-IWU} messages being sent after the { MM-INFO- ACCEPT/REJECT } 
message carrying the first segment. Both MM entities shall use "partial release" to maintain the link open for these 

messages. 

For security reasons before initiating the Fetch bindings procedure the PT shall first cipher the link. The requirements 
for Cipher switching initiated by PT procedure as specified in GAP, EN 300 444 [13], clause 8.34 apply. Figure 10 
provides an example of messages flow of a SIP Fetching bindings procedure when the FT did not have locally stored 
the requested information. 
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Figure 10: Fetching bindings 



7.3.2.1.3 



Refreshing bindings 



The Refreshing bindings procedure relates to the refreshing of the bindings data stored into the FT fcir each user (PT). 
The procedure is specially related to the renewing bindings beftire their expiration interval has elapsed. 

NOTE: Such renewing will be normally based on local network policies. 

This procedure is not explicitly mapped to a DECT procedure because it is a matter to be handled between the FT and 
the IP. 

It is assumed that it is the User's responsibility for an explicit change of her/his bindings. If however, after registration 
and without user intervention, a change in bindings occurs which has impact on the user's capability of receiving calls at 
that particular contact address, e.g. a binding was removed, this shall be indicated to the user with information provided 
in one or more {MM-IWU} messages. 
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Figure 1 1 : Information for bindings chiange 



7.3.2.2 



Message mapping 



For the DECT messages structure and formatting this clause provides references to the relevant requirements specified 
in EN 300 444 GAP [13]. For any requirements to the messages content when used in DPRS or ODAP context see 
EN 301 649 DPRS [16] or TS 102 342 ODAP [32]. 
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7.3.2.2.1 



DECT-SIP message mapping 

Table 13: SIP registration messages List DECT-to-SIP 



Item No 


DECT Message 


SIP Message 


Map status 


Reference 
GAP 


1 


LOCATE-REQUEST 


REGISTER 


M 


8.28 


2 


MM-INFO-REQUEST 


REGISTER 


M 


N/A 


3 


MM-IWU 


REGISTER 


M 


N/A 



Table 14: SIP registration messages List SIP-to-DECT 



Item No 


SIP Message 


DECT Message 


Map status 


Reference 
GAP 


1 


200 OK 


LOCATE-ACCEPT 


M 


8.28 






MM-IWU 


M 


N/A 






MM-INFO-ACCEPT 


M 


N/A 


2 


3. XX, 4xx, 5xx 


LOCATE-REJECT 


M (see note) 


8.28 






MM-IWU 


M 


N/A 


3 


3. XX, 4xx, 5xx 


MM-INFO-REJECT 


M (see note) 


8.28 






MM-IWU 


M 


N/A 


NOTE: The exact error Indications possible during registration are specified in RFC 3261 [18]. 



7.3.2.2.2 



DECT messages/information elements mapping 



For the content of messages/information elements the requirements specified in EN 300 444 GAP [13], 

EN 301 649 DPRS [16] or TS 102 342 ODAP [32], and/or in EN 300 175-5 [5] whenever relevant apply. This clause 

lists only the differences/additions. 

For the structure of the «IWU-TO-IWU» information element the requirements in EN 300 175-5 [5] and annex A of 
the present document apply. Here only the requirements in regard to SIP Registration are indicated. 

NOTE: The segmentation of «IWU-TO-IWU» and its value of the <Protocol discriminator> require additions 
to the DECT CI standard, EN 300 175-5 [5]. Before these changes are implemented they are indicated in 
annex C of the present document. All changes are backwards compatible. 

Table 15: «IWU-TO-IWU» 



Field 


Sub-field 


Value 


Comment 


S/R 




1 




Protocol Discriminator 




100100 


DECT access to IP networks 


Action 


Ext 


1 


Multi octet extension 


Value 


0000010 


SIP REGISTER: Adding/Modifying bindings 


000001 1 


SIP REGISTER: Fetching bindings 


0000100 


SIP REJECT 


Body 




All 


Contains Fields from a SIP Message formatted 
according to RFC 3261 [18] using IA5 character 
set with the additions/modifications as specified in 
the present document. 
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Table 16: «IWU-TO-IWU» Body requirements 



Field 


Format/Comment 


Support 


PT to FT 


FT to PT 


PT 


FT 


FT 


PT 


Start Line 


From the Start line only the Request URI portion needs 
to be supported in the format of "Request-URI: <name- 
addr>". The inclusion of the <Request-URI> field is 
optional. It is assumed that the FT shall have means to 
establish this address. 





M 








Status Line 


Only the "Status-Code" portion needs to be supported for 
on-air transmission in which case the "Reason-Phrase" 
can be locally generated at the FT. 


1 


1 


M 


M 


IVIessage-Header 


For the support of the different Headers see the table 
IVIessage-Header fields support below. 


M 


M 


M 


M 


IViessage body 




1 


1 


1 


1 



Table 17: «IWU-TO-IWU» Body message-Header fields support 



Field 


Format/Comment 


Support 


PT to FT 


FT to PT 


PT 


FT 


FT 


PT 


Authorization 


The format of this field is changed to include the user's 
password: Authorization: username = "name", 
realm = "realm", userpassword = "password" 


M 


M 


N/A 


N/A 


Contact 


See notes 2, 3, and 4 





M 


M 


M 


Error-Info 


Optional to be used together with the Error status code 


N/A 


N/A 








From 


Support of "display name" is optional, only the provision 
of "name-addr" is mandatory, all other parameters are FT 
responsibility matter (see note 5) 





M 








Proxy-Authorization 


The format of this field is changed to include the user's 
password: Proxy-Authorization: username = "name", 
realm = "realm", userpassword = "password" 


M 


M 


N/A 


N/A 


Retry-After 


If included shall be used together with the Error status 
code 


N/A 


N/A 


M 


M 


To 


Support of "display name" is optional, only the provision 
of "name-addr" is mandatory, all other parameters are FT 
responsibility matter (see note 5) 


M 


M 








NOTE 1 : Field's format and values, except otherwise stated in the present document, shall be provided according to 

the requirements specified in RFC 3261 [18] using IA5 character set. To reduce the length of the DECT 

message the compact forms of the header field names shall always be used. 
NOTE 2: The PT may provide none, one or more addresses into the <Contact> field if the user has requested so. It is 

assumed that the FT shall have knowledge as of its own address which shall be used for a contact address 

for registration, the user may provide more. The FT shall provide to the PT its contact address after 

registration if it differs to the name-addr provided in the <From> field. 
NOTE 3: If the User would like to set preferences (priorities) among the addresses in the binding she/he shall provide 

the value of the "q" parameter into the contacts (see RFC 3261 [18]). 
NOTE 4: If the user would like to set Expiration Interval for a binding she/he shall provide the value of the "expires" 

parameter into the contacts (see RFC 3261 [18]). 
NOTE 5: Optionally a User may be provided with capability to SIP register a third party in which case different values 

for the <To> and <From> header fields need to be provided (see RFC 3261 [1 8]). 



The «IWU-TO-IWU» information element may be included, with respect to the procedure performed, into the 
{LOCATE-REQUEST}, { LOG ATE- ACCEPT } , {LOCATE-REJECT}, {MM-INFO-SUGGEST}, 
{MM-INFO-ACCEPT}, {MM-INFO-REJECT} or {MM-IWU} message. For the structure of those messages the 
requirements in EN 300 444 [13], EN 301 649 DPRS [16] or TS 102 342 ODAP [32], or EN 300 175-5 [5] respectively 
apply with the following modifications. 
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Table 18: Values used within a lUlM message 



Information element 


Field within the information 
element 


Standard values within the 
field/information element 


Normative 
action/comment 


«Segmented lnfo» 






See note 2 




<Segmented element type> 


1110111 


«IWU-TO-IWU» 


«IWU-TO-IWU» 




All 


See note 1 


NOTE 1 : For the content of the «IWU-TO-IWU» information element see above. 

NOTE 2: IVIandatory only if the message will exceed 63 octets or when «IWU-TO-IWU» was segmented. 



Table 19: Values used within the {IVIM-INFO-REQUEST} 



Information element 


Field within the information 
element 


Standard values within the 
field/information element 


Normative 
action/comment 


«lnfo type» 










<Parameter type Coding> 


0000110 


Dynamic parameters 
allocation (see note 3) 


«Segmented lnfo» 






See note 2 




<Segmented element type> 


1110111 


«IWU-TO-IWU» 


«IWU-TO-IWU» 




All 


See note 1 


NOTE 1 : For the content of the «IWU-TO-IWU» information element see above. 

NOTE 2: IVIandatory only if the {IVIM-INFO-REQUEST} message will exceed 63 octets. 

NOTE 3: This coding may be used for other purposes as well therefore, implementations complying with the 

present document shall examine the content of the «IWU-TO-IWU} information element, if present, 

before taking any action. 



The following tables provide examples of DECT information elements content in regard to the various registration 
procedures. 

Table 20: «IWU-TO-IWU» Examples - default binding registration (minimum) 



Field 


Sub-field 


Value 


Comment 


Protocol Discriminator 




100100 


DECT access to IP networks 


Action 


Ext 


1 


One octet with action values 




Value 


0000010 


SIP REGISTER: Adding/Modifying 
bindings 


Body 




t: Stoyan <sip:sbaev@etsi.org> 
Authorization: username = baev, 
realm = etsi.org, 
password = dect03 


The inclusion of the "display name" Stoyan 
is optional 


NOTE: Field values shall be formatted according to the requirements specified in RFC 3261 [18] using IA5 character 
set. 



Table 21 : «IWU-TO-IWU» Examples - fetching bindings 



Field 


Sub-field 


Value 


Comment 


Protocol Discriminator 




100100 


DECT access to IP networks 


Action 


Ext 


1 


One octet with action values 




Value 


0000011 


SIP REGISTER: Fetching bindings 


Body 




t: Stoyan <sip:sbaev@etsi.org> 
Authorization: username = baev, 
realm = etsi.org, 
password = dectOS 


The inclusion of the "display name" Stoyan 
if the "t" is included is optional (see note 2) 


NOTE 1 : Field values shall be formatted according to the requirements specified in RFC 3261 [18] using IA5 character 

set. 
NOTE 2: The provision of the <To> field is optional for this procedure, FT shall have a record with the relevant 

information. However, the provision of the field would allow a user to fetch her bindings before registering for 

example when moving to a new FT. 
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Table 22: «IWU-TO-IWU» Examples - registering 2 own contacts with parameters 



Field 


Sub-field 


Value 


Comment 


Protocol Discriminator 




100100 


DECT access to IP networks 


Action 


Ext 


1 


One octet with action values 




Value 


0000010 


SIP REGISTER: Adding/Modifying 
bindings 


Body 




t: Stoyan <sip:sbaev@etsi.org> 
M: "Stoyan" 

<sip:sbaev@einstein.etsi.org>;q = 0,7; 
expires = 3 600, "Stoyan_mail" 
<mailto:stoyan.baev@etsi.org> ;q = 0,1 
Authorization: username = baev, 
realm = etsi.org, password = dect03 


The inclusion of the "display names" 
optional 


NOTE: Field values shall be formatted according to the requirements specified in RFC 3261 [18] using IA5 character 
set. 



Table 23: «IWU-TO-IWU» Examples - removing binding from third party 



Field 


Sub-field 


Value 


Comment 


Protocol Discriminator 




100100 


DECT access to IP networks 


Action 


Ext 


1 


One octet with action values 




Value 


0000010 


SIP REGISTER: Adding/Modifying 
bindings 


Body 




t: Stoyan <sip:sbaev@etsi.org> 
f: Guenter 

<sip:guenter@vienna.com> 
IVI: "Stoyan" 

<sip:sbaev@einstein.etsi.org> 
Authorization: username = guenterk, 
realm = etsi.org, password = epdectc 


The inclusion of the "display names" 
optional 


NOTE: Field values shall be formatted according to the requirements specified in RFC 3261 [18] using IA5 character 
set. 



Table 24: «IWU-TO-IWU» Examples - Reject 



Field 


Sub-field 


Value 


Comment 


Protocol Discriminator 




100100 


DECT access to IP networks 


Action 


Ext 


1 


One octet with action values 




Value 


0000100 


SIP REJECT 


Body 




401 Unauthorized 


The Reason phrase "Unauthorized" is 
mandatory, whereas the Reason code 
"401" is optional 


NOTE: Field values shall be formatted according to the requirements specified in RFC 3261 [18] using IA5 character 
set. 



7.3.3 Call control 



7.3.3.1 



Procedure mapping 



The main purpose of the SIP signalHng protocol (RFC 3261 [18]) is the establishment, modification (if needed), and 
termination of interactive multimedia sessions. These sessions include Internet telephone calls, multimedia distribution, 
and multimedia conferences. The SIP invitations used to create sessions carry contact information as well as session 
descriptions that allow participants to agree on a set of compatible media types (users may communicate in several 
different media - sometimes simultaneously). The session descriptions are carried in the SIP message <sdp> field 
(see RFC 3261 [18]) and are specified in the RFC 2327: Session Description Protocol (SDP) [19]. 
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From DECT point of view a SIP session can be mapped to a DECT call and consequently a session establishment and 
termination can be mapped to a call establishment and termination. The call setup related procedures and the release 
procedure shall be performed in the case of a voice call as defined in GAP, EN 300 444 [13] with the modifications 
described in the present document. For non voice media types the call related procedures shall be performed either as in 
DPRS, EN 301 649 [16] (high data rate option) or as in ODAP, TS 102 342 [32] (low data rate option). 

If the user wants to communicate using different media simultaneously for each media type an independent DECT call 
shall be established. Media types that use the DPRS as a transport shall use the DPRS DECT generic media 
encapsulation transport mechanism as defined in EN 301 649 DPRS [16] and may use one and the same call for 
simultaneous exchange of different types of media. Modification of a session from one media type to another may use 
the same call or terminate the existing and establish a new one. 

To allow different calls and/or media streams to be related to one and the same session the FT shall, after a session ID 
(the value of the <Call-ID> field of a SIP message as defined in RFC 3261 [18]) is allocated (INVITE sent/received), 
provide the user (via the PT), at the first possible occasion, with the session ID. When adding a new PT to the session 
the user shall be able to provide (key-in) the session ID to that PT. The SIP protocol may calculate and assign a not 
easily readable <Call-ID>, therefore FTs are allowed to use locally, i.e. within the DECT system, simpler identifiers as 
long as they are preserved unique and are associated with the real <Call-ID> used in the communication with the 
external network. 

Upon user request for a call establishment the PT shall initiate an outgoing call setup procedure and provide all 
necessary information. The support of provision of the called party address information (the <To>) is mandatory. 

If the initiated session is to be a voice only the inclusion of session description is optional and its omission shall be 
understood as a request for a voice only session. The type of media "audio" is the media type that is to be used in regard 
to voice. The various audio encodings identifiers are defined in RFC 3550 [30] and RFC 3551 [31]. Standard voice 
codex used by DECT is the G726-32. If other audio encodings are used during a SIP session it is the responsibility of 
the FT to perform conversion or to reject their usage. The conversion is out of the scope of the present document. 

If the user wants different than voice type(s) of media to be used the media description shall be provided; alternatively, 
the user may leave the type of media, i.e. the session description, to be chosen by the called party (see RFC 3261 [18] 
for details) by including an empty <sdp> field.. The session description, when provided, shall use the format described 
in RFC 2327 [19]: "Session Description Protocol (SDP)" and used in SIP RFC 3261 [18]. A PT should provide session 
description including only the media types it can handle and if the user would like to use another PT with the same 
session the addition of its media types should be handled through modification of the session (i.e. through re-INVITE). 

The SIP session related information shall be provided using the «IWU-TO-IWU» element segmented, if needed, into 
one or more consecutive {IWU-INFOj messages. The fragmentation is required if the message will exceed 63 octets if 
the complete «IWU-TO-IWU» information element is included. It is allowed that the «IWU-TO-IWU» is 
included already in the {CC-SETUPj message if sufficient information is available. FT shall re-assemble the received 
information, if segmented, in the order of arrival of the «IWU-TO-IWU> fragments. The FT should store the media 
capabilities in the relevant PT record. 

At the FT side, as soon as all necessary information is available the FT shall initiate towards the IP network a SIP 
session establishment. The FT shall include in the first message sent back to the PT the session ID. 

Indication for the status of the session establishment, e.g. called party has been alerted (180 Ringing SIP message), may 
be mapped back to PT. 

The agreed parameters of the session in case of a voice only session may be conveyed back to the PT and shall be 
conveyed back to the PT for sessions including other than voice types of media. The {CC-CONNECTj message and/or 
one or more {IWU-INFOj messages shall be used. For sessions including media types different than voice if the 
{CC-CONNECTj message does not contain information relevant to the session the connect shall be treated as a connect 
only to the FT and connect to the called party may be assumed by the PT only after session information is received. In 
the case of voice media, after the SIP session is established the voice (audio) path will be connected and conversion 
between IP and DECT voice will occur at the FT side; for other types of media the relevant media protocol will start 
transmission of the protocol's datagrams. Examples of mapping between the DECT outgoing call establishment and 
release procedures and the SIP session establishment and termination procedures are provided in figures 12 to 14. 
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Figure 12: Successful SIP session establishment and termination Outgoing call (GAP) 
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Figure 13: Successful SIP session establishment and termination Outgoing call (DPRS) 
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Figure 14: Successful SIP session establishment called party chooses session description 

In the case of an incoming call, the attempt of a SIP session establishment (i.e. the arrival of an INVITE message) will 
be detected at the FT side. This, if the desired session is acceptable, will result into an incoming call establishment 
towards the PT. 
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Based on the user's AOR and the session description (if provided) the FT shall determine which PT to call. If session 
description is not provided and the user (identified by its AOR) has used multiple PTs (e.g. for different types of media) 
the FT should ring all PTs and the one that the user answers first should determine the session media description. 
Alternatively a PT may be chosen as a default, e.g. a GAP voice PT, which will be rang in such circumstances. 

The session ID, the Caller address information (CLIP in GAP) and/or the Session description information, if provided in 
the INVITE, shall be provided into the «IWU-TO-IWU» information element included into the {CC-SETUP} 
message, segmented if necessary in one or more consecutive {IWU-INFO} messages. FT may chose not to include 
session description for voice only sessions and calls to voice only capable PTs. 

When accepting the call the user may, if media description is suggested, accept or suggest modification to the type of 
media indicated in the session description. If an empty <sdp> field has been provided, i.e. the choice has been left to the 
called party, when accepting the call the user shall suggest session media type(s) (see note below). The Session 
description information shall be provided into the «IWU-TO-IWU» information element included into the 
{CC-CONNECT} message, segmented if necessary and in one or more consecutive {IWU-INFO} messages. As soon 
as all the necessary information is collected the FT shall map it to a 200 OK message. 

NOTE: Voice only terminals need not be able to provide/handle session descriptions. Sessions with such 
terminals are assumed to be by default of type voice. 

If session description was first suggested by the called party, the acceptance of it ( ACK message) shall be provided into 
the «IWU-TO-IWU» information element included into the {CC-CONNECT- ACK} message, segmented if 
necessary and in one or more consecutive {IWU-INFO} messages. 

Examples of the mapping between the DECT incoming call establishment and release procedures and the SIP session 
establishment and termination procedures are provided in figures 15 and 16. 
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Figure 15: Successful SIP session establishment and termination Incoming call 
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Figure 16: Incoming call - called party suggests sessions description 

An attempt for SIP session establishment may be unsuccessful. The reason will be indicated by the response type send 
to the FT from the Proxy. Some reasons may be handled at the FT whereas others may need a user action and shall be 
conveyed to the user. An example of unsuccessful SIP session establishment because the called party is not any longer 
available at the provided <To> address is shown in figure 17. 
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Figure 17: Unsuccessful SIP session establishment Outgoing call 

If the initiating party decide to terminate its request before a call/session has been established the DECT 
abnormal/normal release procedure may be mapped to the SIP CANCEL or BYE procedures and may be delayed 
depending on the status of the SIP session establishment (see RFC 3261 [18]). An incoming SIP CANCEL shall be 
mapped to DECT abnormal/normal release procedure. An example of delayed mapping between a DECT release and 
SIP CANCEL is shown in figure 18. 
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Figure 18: Calling party release before call establishment completed 

By default a session shall be assumed to be a voice session in which case session description needs not be sent by the 
initiating PT side. It is the responsibility of the FT-UA to provide the correct relevant session description (audio type as 
defined in RFC 3261 [18] and RFC 2327 [19]) towards the IP network upon SIP session establishment. In all other 
cases session description information shall be provided to the receiving side into the relevant CC message and one or 
more {IWU-INFOj messages each of maximum length of 63 octets (see GAP [13], clause 6.9.3) included into the 
«IWU-TO-IWU» information element. When necessary this information element shall be segmented and included in 
consecutive {IWU-INFO} messages. If segmentation is used each message shall contain the «SEGMENTED-INFO» 
information element. Each message should contain the maximum amount of service data (of user information). On the 
receipt side the received information shall be re-assembled. 

A session establishment may be rejected. If a request for session establishment results not in a <200 OK> but in an 
error, certain error reasons shall be conveyed to the PT as corresponding reject reasons included into 
«IWU-TO-IWU» information element in a { CC-RELEASE } or {CC-RELEASE-COMj message as appropriate. If 
the «IWU-TO-IWU» was included into a {CC-RELEASE-COMj and segmented in one or more consecutive 
{IWU-INFO} messages, the receiving CC entity shall not request link release before all information was received. 

FT shall distinguish the following general types of rejections: 

a) A problem that can be solved at the FT-UA, e.g. problem related to IP. In this case FT-UA shall not reject the 
DECT call establishment and shall do whatever necessary to solve the problem. Optionally, FT may inform the 
PT for the problem providing the SIP reject coding information into a {IWU-INFO} message using the 
«IWU-TO-IWU» information element. PT shall inform the user for the outcome displaying parts or all of 
the information received into the «IWU-TO-IWU» information element. Additionally FT may need to 
restart the timer running at the PT and guarding the PT CC state. 

b) A problem that can be solved at the FT-UA but it requires user agreement, e.g. call re-direction. In this case 
FT-UA shall not reject the DECT call establishment and shall inform the PT for the problem providing the SIP 
reject coding information and any additional information, e.g. suggested new addresses, into one or more 
{IWU-INFO} message using the «IWU-TO-IWU» information element (segmented if needed). PT shall 
inform the user for the outcome displaying parts or all of the information received into the 
«IWU-TO-IWU» information element. The FT shall not proceed with the IP action before the user gives 
OK to the FT to proceed in a {IWU-INFO} response message. The user may permit the FT to make choice on 
its own or the user may make the choice and provide it. FT may need to restart the timer running at the PT 
guarding the PT CC state. 

c) A problem that was due to the user input, or user information. In this case FT-UA shall not reject the DECT 
call establishment and shall inform the PT for the problem providing the SIP reject coding information and any 
additional information, if available, into one or more {IWU-INFO} message using the «IWU-TO-IWU» 
information element (segmented if needed). PT shall inform the user for the outcome displaying parts or all of 
the information received into the «IWU-TO-IWU» information element. The User should re-submit the 
information required. For problems related to the users confidentiality parameters see clause Security later on. 

d) All other problems, e.g. such that cannot be solved within the call establishment procedure, shall be rejected 
and reason code provided. 
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An example of reject type a) is provided in figure 19. 
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Figure 19: SIP session establishment after reject due to address related issue 



Message mapping 



For the DECT messages structure and formatting this clause provides references to the relevant requirements in 
EN 300 444 GAP [13]. For any requirements to the messages content when used in DPRS or ODAP context 
see EN 301 649 DPRS [16] or TS 102 342 ODAP [32]. 



7.3.3.2.1 



DECT-SIP message mapping 



Table 25: SIP session establishment messages list DECT-to-SIP 



Item No 


DECT Message 


SIP Message 


Map status 


Reference 
GAP 


1 


CC-SETUP 


INVITE 


M 


8.2 


IWU-INFO 


N/A 








M 






N/A 


2 


CC-RELEASE 


BYE, CANCEL 


0(note 1) 


8.7 


IWU-INFO 


N/A 


3 


CC-RELEASE-COM 


BYE, CANCEL 


0(note 1) 


8.8 


IWU-INFO 


N/A 


4 


CC-ALERTING 


180 


M (note 2) 


8.14 


IWU-INFO 


N/A 


5 


CC-CONNECT 


200 


M (note 2) 


8.15 


IWU-INFO 


N/A 


6 


IWU-INFO 


INVITE, ACK 


M 


N/A 


NOTE 1 : It is left to the FT implementation to decide whether and how to map these DECT 

messages in relation to the SIP session establishment requirements. 
NOTE 2: Incoming call. 
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Table 26: SIP session establishment messages list SIP-to-DECT 



Item No 


SIP Message 


DECT Message 


Map status 


Reference 
GAP 


1 


INVITE 


CC-SETUP 


M 


8.12 


IWU-INFO 


M 


N/A 


2 


BYE 


CC-RELEASE 


M 


8.7 


IWU-INFO 


M 


N/A 


3 


ACK 


CC-CONNECT-ACK 


M 


8.15 


IWU-INFO 


M 


N/A 


4 


CANCEL 


CC-RELEASE, 
CC-RELEASE-COM 


M 


8.7, 8.8 


IWU-INFO 


M 


N/A 


5 


200 


CC-CONNECT 


M (note 1) 


8.6 


IWU-INFO 


M 


N/A 


7 


180 


CC-ALERTING 


C (note 2) 


8.5 


IWU-INFO 


M 


N/A 


8 


100 


CC-CALL-PROC 


C (note 2) 


8.4 


9 


181, 182,301,302 


IWU-INFO 


M 


N/A 


10 


300, 400, 401 , 403, 404, 408, 41 0, 
480, 484, 485, 486, 5xx, 600, 603, 604 


CC-RELEASE, 
CC-RELEASE-COM 


M 


8.7, 8.8 


IWU-INFO 


M 


N/A 


NOTE 1 : When answer to INVITE for outgoing call. 

NOTE 2: For Outgoing call a manufacturer may decide to skip some DECT CC states 

(see GAP [13]) - the FT-UA will generate/handle the relevant SIP messages as 

appropriate. 



7.3.3.2.2 



DECT messages/information elements mapping 



For the content of messages/information elements the requirements specified in EN 300 444 GAP [13], 

EN 301 649 DPRS [16] or TS 102 342 ODAP [32], and/or in EN 300 175-5 [5] whenever relevant apply. This clause 

lists only the differences/additions. 

For the structure of the «IWU-TO-IWU» information element the requirements in EN 300 175-5 [5] and annex A of 
the present document apply. Here only the requirements in regard to SIP Session establishment are indicated. 

Table 27: «IWU-TO-IWU» 



Field 


Sub-field 


Value 


Comment 


S/R 




1 




Action 


Ext 


1 


Multi octet extension 




Value 


0001000 


SIP SESSION ESTABLISHMENT 


Body 




All 


Contains Fields from a SIP Message formatted 
according to RFC 3261 [18] using IA5 character 
set with the additions/modifications as specified in 
the present document. 



The following tables indicate the SIP message fields that may be carried in the Body field of the «IWU-TO-IWU» 
SIP related information. Whether provision/understanding is required is indicated. 
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Table 28: «IWU-TO-IWU» Body 



Field 


Format/Comment 


Support 


PT to FT 


FT to PT 


PT 


FT 


FT 


PT 


Start Line 


From the Start line only the Request URI portion needs 
to be supported in the format of "Request-URI: <name- 
addr>". The inclusion of the <Request-URI> field is 
optional. It is assumed that the FT shall have means to 
establish this address. 





M 








Status Line 


Only the "Status-Code" portion needs to be supported for 
on-air transmission in which case the "Reason-Phrase" 
shall be locally generated at the PT. For the support of 
the different Status-Codes see the table Status-Codes 
field support below. 


C1 


C1 


M 


M 


IVlessage-Header 


For the support of the different Headers see the table 
Message-Header fields support below. 


M 


M 


M 


M 


IVIessage body 


For the support of different Message bodies see the table 
Message-body fields support. 


C2 


C2 


C2 


C2 


C1 : IF only voice supported THEN 1, ELSE M. 
C2: IF only voice supported THEN 0, ELSE M. 



The provision and understanding of the following Status Codes shall be supported by FT and PT respectively. 



£75/ 



52 



ETSI TS 102 265 V1.2.1 (2004-10) 



Table 29: «IWU-TO-IWU» Body: Status line / Status codes 



Sautes 
Code 


Reason phrase 


Normative action/comment 


181 


Call Is Being Forwarded 


The calling party User should be informed. User may release the call setup. 


182 


Queued 


The calling party User shall be informed that the request has been queued rather 
than rejected. User may wait or release the call. 


300 


Multiple Choices 


The calling party User shall be informed that the address in the request resolved 
to several choices, each with its own specific location. The locations shall be 
indicated as provided by the remote server. The calling user shall be capable of 
choosing location from those provided. The PT shall send the new contact 
address to the FT in a <To> field. 


301 


Moved Permanently 


The provision of these status codes to the PT and user is optional - FT my 
process the new contacts provided with the response as specified in the 
RFC 3261 [18] without informing the user. Alternatively, the FT may provide the 
response code and the Contact details to the PT in which case the calling user 
shall be informed for the problem and provided with the possibility of choosing one 
new address from those indicated. The PT shall send the new contact address to 
the FT in a <To> field and this shall be used by the FT for a new INVITE. 


302 


Moved Temporarily 


400 


Bad Request 


The calling party User shall be informed. The user needs to resent the address 


401 


Unauthorized 


If the FT is not able to retrieve credentials from the stored in the PT/user record it 
shall send this code to the PT together with the realm{s) causing the problem. The 
calling party User shall be informed and the realm(s) causing the problem 
provided. The user needs to send its credentials for each realm (if multiple): user 
name, password and realm. If the user does not have credential for a realm then 
user name = "anonymous" and password = "" shall be provided. If these are not 
accepted by the realm causing the problem the call shall be released and the 
reason indicated. 


407 


Proxy Authorization 
Required 


403 


Forbidden 


Call shall be released. The calling party User shall be informed for the reason (this 
may be received in result of a failed authorization). 


404 


Not Found 


Call shall be released. The calling party User shall be informed for the reason. 


408 


Request Timeout 


The FT-UA has retried few times but still it does not work. The calling party User 
shall be informed for the reason. 


410 


Gone 


Call shall be released. The calling party User shall be informed for the reason. 


480 


Temporarily Unavailable 


Call shall be released. The calling party User shall be informed for the reason. 


484 


Address Incomplete 


The calling party User shall be informed. User may retry to provide the address or 
release the call. 


485 


Ambiguous 


486 


Busy Here 


The calling party User shall be informed. User may retry another contact. 


5xx 


Server Failure 


Call shall be released. The calling party User shall be informed for the reason. 


600 


Busy Everywhere 


Busy tone. 


603 


Decline 


Call shall be released. The calling party User shall be informed for the reason. 


604 


Does Not Exist Anywhere 


Call shall be released. The calling party User shall be informed for the reason. 



The requirements to FT and PT respectively of provision/understanding of the various SIP message header fields are 
indicated in table 30. The table does not represent an exhaustive list of all SIP headers and other headers can optionally 
be supported as specified in RFC 3261 [18]. 
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Table 30: «IWU-TO-IWU» Body: Message-Header fields support 



Field 


Format/Comment 


Support 


PT to FT 


FT to PT 


PT 


FT 


FT 


PT 


Accept 




C2I 


C3I 


C2 


C3I 


Accept-Language 


Default is English - FT needs not to support any other 
language. It is the PT's responsibility to convert to/from 
any other chosen by the user language for local 
presentation. 














Alert-Info 


Neither the FT nor the PT are required to be able to 
handle additional ringing tones. If they do not support a 
tone being requested, they shall map it to whatever tone 
appropriate. 














Authorization 


Not required to be provided, unless explicitly requested, 
see later the clause about Security. 








N/A 


N/A 


Call-ID 


Used to relate a new call to an existing session 


C4 


M 


M 


M 


Call-Info 
















Contact 
















Content-Disposition 


See note 4 














Content-Encoding 


See note 4 














Content-Language 


See note 4 














Content-Length 


See note 4 


C1 


C1 


C1 


C1 


Content-Type 


See note 4 


C1 


C1 


C1 


C1 


Error-Info 




N/A 


N/A 








From 


See note 3 














Organization 


Optional may be used for call incoming filtering 














Priority 


Mandatory, with default "normal" 





M 





M 


Proxy-Authorization 


Not required to be provided, unless explicitly requested, 
see later the clause about Security. 








N/A 


N/A 


Reply-To 


See note 3 














Retry-After 




N/A 


N/A 


M 


M 


Subject 
















To 


See note 3 


M 


M 








CI : IF only voice supported THEN 0, ELSE M. 

C2: IF only voice supported THEN 1, ELSE 0. 

C3: IF only voice supported THEN 1, ELSE M. 

C4: IF adding a new terminal to an existing session supported THEN M, ELSE 1. 


NOTE 1 : Field's format and values, except otherwise stated in the present document, shall be provided according to 

the requirements specified in RFC 3261 [1 8]. To reduce the length of the DECT message the compact 

forms of the header field names shall always be used. 
NOTE 2: The minimum requirements for support at the PT side are the provision of just its AOR into the <To> header 

field. Consequently it is required that the FT shall be capable of obtaining/computing all the rest necessary 

information for the construction of the REQUEST message. 
NOTE 3: Support of "display name" is optional, only the provision of "name-addr" is mandatory, all other parameters 

are FT matter. 
NOTE 4: Related to message body (see the table IVIessage-body fields support for additional information). 
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The requirements to FT and PT respectively of provision/understanding of SIP message bodies and related header fields 
are indicated in table 3 1 . 

Table 31 : «IWU-TO-IWU» Body: Message-body related fields support 



Field 


Format/Comment 


Support 


PT to FT 


FT to PT 


PT 


FT 


FT 


PT 


Content-Disposition 


(see note 1 ) 
















"session" 


M 


M 


M 


M 




"render", "icon", "alert" 








M 


M 




"optionarTrequired" 





M 


M 


M 


Content-Language 


















"en" 


M 


M 


M 


M 


Content-Type 




CI 


C1 


C1 


C1 




"application/sdp" (see note 2) 


M 


M 


M 


M 




"text/*", "image/*", "audio/*", "video/*", "application/*" 














Content-Length 




CI 


C1 


C1 


C1 




(see note 2) 





M 


M 


M 




>0 





M 


M 


M 


IVIessage Body 


(see note 3) 


CI 


C1 


C1 


CI 




when type "application/sdp" (see note 2) 


M 


M 


M 


M 




when type not "application/sdp" 














C1 : IF only voice supported THEN 0, ELSE IVI. 
C2: IF only voice supported THEN 1, ELSE 0. 
C3: IF only voice supported THEN 1, ELSE M. 


NOTE 1 : If FT receives this filed from the IP network it shall convey it to the PT and the PT shall be able to 

understand the content and react upon it. PT is required to support only the value "session". If other value is 
indicated which is not supported and the status has been set to "required" the PT shall reject the invitation 
as defined in RFC 3261 [18]. 

NOTE 2: A terminal shall indicate "application/sdp" and "0" if it wants the called party to suggest session description; 
IVIessage body shall not be included in this case. 

NOTE 3: In the case of voice only sessions the PT is not required to provide/understand session description. The lack 
of information being provided by the PT shall be interpreted as message bodies of type "application/sdp" 
related to audio sessions was indicated and, it is the responsibility of the FT to construct the relevant 
session description information in regard to the requirements of the SIP (RFC 3261 [18]) and SDP 
(RFC 2327 [19]). 



The «IWU-TO-IWU» information element may be included, with respect to the CC state and procedure performed, 
in any CC message that is relevant. If the inclusion of the «IWU-TO-IWU» into a message will result into the 
message length being higher than 63 octets, the «IWU-TO-IWU» shall be segmented. The second and following 
segments shall be included into one or more {IWU-INFO} messages. A first segment can be placed in a {IWU-INFO} 
message as well. The sending side shall not initiate transmission of a new «IWU-TO-IWU» information element 
before all segments of a previous one have been submitted. For the structure of the possible messages the requirements 
in EN 300 444 GAP [13], EN 301 649 DPRS [16] or TS 102 342 ODAP [32], or EN 300 175-5 [5] respectively apply 
with the following additions. 

Table 32: Values used within a CC message 



Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Segmented 
lnfo» 






See note 2 




<Segmented element 
type> 


1110111 


«IWU-TO-IWU» 


«IWU-T0-IWU» 




All 


See note 1 


NOTE 1 : For the content of the «IWU-TO-IWU» information element see above. 

NOTE 2: Mandatory only if the CC message will exceed 63 octets or if the «IWU-TO-IWU» is segmented. 
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7.3.4 Service (session) attributes negotiation/modification 

Session attributes are negotiated at session establishment time by exchange of session descriptions. The rules are 
specified in SIP (RFC 3261 [18]) and the PT/FT behaviour on the DECT air interface is described in clause 7.3.3 of the 
present document (Call control). Session modification is described in this clause. 

After a session has been established and session description agreed the session may be modified due to various reasons. 
Some examples include: the user would like to add a new media, e.g. in a voice session the user would like to send 
images from a camera; a new user would like to join the session which may be participating through different type of 
media; a participant would like to change its location, etc. The session modification, as defined in SIP (RFC 3261 [18]), 
is executed by exchanging within the same dialog (session) the usual SIP messages used for a session establishment, 
e.g. INVITE, 200 OK, ACK, etc. carrying a new session description, that is a new SDP body. The new session 
description provides the new media types, the types which were in use and will be still in use, as well as, information 
for types, if any, that may need to be excluded. 

For a Session modification negotiation on the DECT air interface the exchange of {IWU-INFO} messages shall be used 
as defined in this clause. 

7.3.4.1 FT initiated session modification procedure 

The FT shall initiate a session modification procedure on the DECT air interface if within an established session it 
receives a new INVITE request indicating session modification. If the change was due to a change in the location of the 
far end user, the FT may handle this locally and need not inform the PT. 

PTs that support only voice sessions need not to support the session modification procedure. Consequently they may not 
be able to understand and respond to a session modification request initiated by the FT. The lack of response shall be 
treated by the FT as rejection of the requested change if different than voice media types were requested. 

Before initiating the session modification on the DECT air interface, the FT shall examine the records of the registered 
SIP capable PTs of the participants involved in the session and shall identify those that are capable to handle at least one 
of the media types included in the session description. If necessary the capabilities of these PTs may be enquired (see 
clause 7.3.6). 

The FT shall initiate the session modification procedure with all PTs involved in the session that may be concerned by 
the modification by sending a {IWU-INFO} message. The «IWU-TO-IWU» information element shall be included 
to describe the new session. 

For PTs that are not currently involved in the session but still being capable of handling some of the media types the FT 
shall initiate an incoming call and invite them to take part (for call establishment requirements see clause 7.3.3). 

At the PT side the modifications should be indicated to the user allowing for user's acceptance or rejection. Each 
terminal involved in a session modification shall indicate acceptance or rejection based only on its own capabilities. The 
{IWU-INFO} message shall be used. The «IWU-TO-IWU» information element shall be included to providing the 
session details the terminal can accept. 

The FT shall collect the answers from all old and new (if any) terminals and shall construct the answer to the SIP 
network to include all relevant media types and details agreed, modified and/or rejected. The FT shall consider the 
terminals involved on the DECT air interface and their media capabilities as a single terminal capable of providing all 
indicated to be supported media types. 

In any case if the inclusion of the «IWU-TO-IWU» into a message will result into the message length being higher 
than 63 octets, the «IWU-TO-IWU» shall be segmented into one or more {IWU-INFO} messages. The sending side 
shall not initiate transmission of a new «IWU-TO-IWU» information element before all segments of a previous one 
have been submitted. For the requirements in regard to the message/information element content see clause 7.3.4.3. 

7.3.4.2 PT initiated session modification procedure 

The PT shall initiate a session modification procedure on the DECT air interface if within an established session the 
user of the PT would like to add a new media type that the same PT can handle. 

Optionally a PT may provide means to the user to add or modify media which the PT it is not capable of handling and 
even of a session it is not participating in. 
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NOTE 1 : This provision is relevant for a kind of a configuration purposes. 

PTs that are not currently involved in a session may join in and thereby require a session modification, e.g. if they 
handle media type that is not currently included in the session description. On the DECT air interface this shall be 
handled by an outgoing call to the FT that controls the session (for call establishment requirements see clause 7.3.3). It 
is the FT responsibility to request modification of the session on the SIP network side. The session description carried 
into the answer of the network (a SIP 200 OK message) shall be conveyed to the participants if the modification has any 
impact to them. The PTs that are not aware of the initiation of the session modification shall consider this, possibly new, 
session description as initiation of session modification and shall respond accordingly to the requirements specified in 
clause 7.3.4.1. 

The PT shall initiate the session modification procedure by sending a {IWU-INFO} message. The «IWU-TO-IWU» 
information element shall be included to indicate the session ID and describe the new session. In any case if the 
inclusion of the «IWU-TO-IWU» into a message will result into the message length being higher than 63 octets, the 
«IWU-TO-IWU» shall be segmented into one or more {IWU-INFO} messages. The sending side shall not initiate 
transmission of a new «IWU-TO-IWU» information element before all segments of a previous one have been 
submitted. For the requirements in regard to the message/information element content see clause 7.3.4.3. 

NOTE 2: To request session modification of a session in which the PT is not involved, the PT needs to know and 
provide the session ID. 

Upon the receipt of a request for session modification the FT shall try to map the session description into a re-INVITE 
message as defined in SIP (RFC 3261 [18]). If this is not possible the FT shall return a not modified session description 
to the PT and shall not initiate session modification towards the SIP network. If the mapping is possible, the FT shall 
initiate a session modification towards the SIP network. The result, the accepted session description, shall be 
communicated back to the PT initiator and all participant PTs that may be impacted by the modification, optionally the 
information may be sent also to participant PTs that will not be impacted by the change. The PTs that are not aware of 
the initiation of the session modification shall consider this, possibly new, session description as initiation of session 
modification and shall respond accordingly to the requirements specified in clause 7.3.4.1. 

If the inclusion of the «IWU-TO-IWU» into a message will result into the message length being higher than 
63 octets, the «IWU-TO-IWU» shall be segmented into one or more {IWU-INFO} messages. The sending side shall 
not initiate transmission of a new «IWU-TO-IWU» information element before all segments of a previous one have 
been submitted. For the requirements in regard to the message/information element content see clause 7.3.4.3. 

7.3.4.3 Message mapping 

7.3.4.3.1 DECT-SIP message mapping 

Table 33: SIP registration messages list DECT-to-SIP 



Item No 


DECT Message 


SIP Message 


Map status 


Reference 
GAP 


1 


IWU-INFO 


(re)INVITE, ACK 


M 


N/A 



Table 34: SIP registration messages list SIP-to-DECT 



Item No 


SIP Message 


DECT Message 


Map status 


Reference 
GAP 


1 


(re)INVITE 


IWU-INFO 


M 


N/A 


2 


200 OK 


IWU-INFO 


M 


N/A 



7.3.4.3.2 



DECT messages/information elements mapping 



For the content of messages/information elements the requirements specified in EN 300 444 GAP [13], 

EN 301 649 DPRS [16] or TS 102 342 ODAP [32], and/or in EN 300 175-5 [5] whenever relevant apply. This clause 

lists only the differences/additions. 

For the structure of the «IWU-TO-IWU» information element the requirements in EN 300 175-5 [5] and annex A of 
the present document apply. Here only the requirements in regard to SIP session modification are indicated. 
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Table 35: «IWU-TO-IWU» 



Field 


Sub-field 


Value 


Comment 


S/R 




1 




Action 


Ext 


1 


Multi octet extension 




Value 


0001001 


SIP SESSION MODIFICATION 


Body 




All 


Contains Fields from a SIP Message formatted 
according to RFC 3261 [18] using IA5 character 
set with the additions/modifications as specified in 
the present document. 



For the structure of the Body field of the «IWU-TO-IWU» see clause 7.3.3.2.2. 

For the provision and understanding of the Status Codes see clause 7.3.3.2.2. Error codes during session modification in 
the normal case should not lead to release of the call and should be seen as having impact mainly on the session 
modification itself 

Only the mandatory requirements of provision/understanding of the SIP message header fields are indicated in table 36. 
For other optional for support headers see clause 7.3.3.2.2. 

Table 36: «IWU-TO-IWU» Body: Message-Header fields support 



Field 


Format/Comment 


Support 


PT to FT 


FT to PT 


PT 


FT 


FT 


PT 


Call-ID 




M 


M 


M 


M 


Content-Type 


"session/sdp" 


M 


M 


M 


M 



The requirements to FT and PT respectively of provision/understanding of SIP message body is indicated in table 37. 
Table 37: «IWU-TO-IWU» Body: Message-body support 



Field 


Format/Comment 


Support 


PT to FT 


FT to PT 


PT 


FT 


FT 


PT 


Message Body 


Full session description as defined in SIP 
(RFC 3261 [18]) and SDP (RFC 2327 [19]) using IA5 
character set 


M 


M 


M 


M 



Table 38: Values used within a IWU-INFO message 



Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Segmented 
lnfo» 






Mandatory only if the IWU-INFO message 
will exceed 63 octets. For the requirements 
in regard to the usage of this IE see 
EN 300 175-5 [5] 




<Segmented element 
type> 


1110111 


«IWU-TO-IWU» 


«IWU-TO-IWU» 




All 


For the content of the «IWU-TO-IWU» 
information element see above 
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7.3.5 Security 



7.3.5.1 Procedure mapping 

The security issues in regard to DECT-SIP interworking can be divided into two groups: 

• Those related to secure transmission over the DECT air interface of SIP related authorization parameters, 
e.g. user name, password and realm. 

• Those related to security issues in regard to the SIP and related protocols. 

To provide a secure transmission of SIP related authorization parameters over the DECT air interface every terminal 
that claims compliance with the present document shall prior to transmitting those parameters cipher the DECT link. It 
is the responsibility of the PT to ensure the secure transmission of the user's credentials. Consequently it is mandatory 
for both, the PT and the FT, to support the PT initiated Ciphering procedure as defined in GAP EN 300 444 [13]. 

During Registration phase, and during any procedure related to registration, the user shall provide its name, password 
and realm as specified in clause 7.3.2 earlier. The FT shall store the provided information into the user/PT record and 
shall use it for authentication/authorization purposes during session establishment as specified into the RFC 3261 [18] 
(e.g. during session establishment the user is challenged by the realm for which credential information is stored). 

If during a particular SIP procedure, e.g. session establishment, the FT needs to retrieve the user credentials, e.g. a 
Proxy Authorization on the path challenge is received from a realm for which FT does not have a record, it shall 
provide to the PT the realm that requests the relevant authorization parameters. The PT shall request the user to enter 
password and username for this realm and provide them back to the FT. The {IWU-INFOj messages shall be used 
during call establishment and {MM-IWUj during standalone MM procedures, e.g. registration. Prior to sending the 
response, if the link is in clear mode, the PT shall cipher the link. 
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Figure 20: SIP session establishment credential retrieval example 

For the message/information elements requirements and mapping see clause 7.3.3.2. 

Table 39: «IWU-TO-IWU» Examples - Proxy authorization request FT to PT 



Field 


Sub-field 


Value 


Comment 


Protocol Discriminator 




100100 


DECT access to IP networks 


Action 


Ext 


1 


One octet with action values 




Value 


0000100 


SIP REJECT 


Body 




407 Proxy Authorization Required 

Proxy-Authorization: 

realm = vienna.com 


The reason phrase Proxy Authorization 
Required is optional but may be used to 
be displayed to the user 


NOTE: Field values shall be formatted according to the requirements specified in RFC 3261 [18]. 
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Table 40: «IWU-TO-IWU» Examples - Proxy authorization response PT to FT 



Field 


Sub-field 


Value 


Comment 


Protocol Discriminator 




100100 


DECT access to IP networks 


Action 


Ext 


1 


One octet with action values 




Value 


0000100 


SIP REJECT 


Body 




Authorization: username = stoyan, 
realm = vienna.com, password = 123 




NOTE: Field values shall be formatted according to the requirements specified in RFC 3261 [18]. 



The security at the IP side is left to the FT implementer and hence is out of the scope of the present document. 

NOTE: Certain activities at the IP may need to be indicated to the user and in some cases a confirmation from the 
user may be expected before the FT proceeds further with the IP action. An example of such event is the 
possibility for redirection of a call from a sips address to a sip address (see RFC 3261 [18]), i.e. from a 
secure address to an insecure one. For handling of such cases see clause 7.3.2. 

7.3.6 Query for capabilities 

The SIP method OPTIONS allows a UA to inquire another UA or a proxy server for its capabilities 
(see RFC 3261 [18]). This allows a client to discover information about the supported methods, content types, 
extensions, codecs, etc. without "ringing" the other party. This procedure can normally be handled by the FT-UA 
without the PT being engaged depending on the FT SIP capabilities and the already stored, if sufficient, information 
about the PT's capabilities. 

This clause specifies requirements only in regard to the indication/query of the PT's capabilities. The FT's SIP 
capabilities depend on the implementation of the SIP protocol in the FT which shall be in accordance with the 
requirements specified in RFC 3261 [18]. 

7.3.6.1 FT initiated query for PT capabilities 

FT shall be capable of querying PT's SIP related capabilities explicitly whenever this is necessary. It is suggested that 
FT performs a PT capabilities query immediately after PT's SIP registration. 

NOTE: PTs will provide information on its capabilities implicitly during session establishment. 

For query of the PT's SIP capabilities the FT shall use the DECT External protocol information procedure as defined in 
EN 300 175-5 [5], clause 13.9. The FT shall include in the {MM-IWU} message an «IWU-TO-IWU» information 
element indicating <SIP TERMINAL CAPABILITIES>. Upon receipt of this message PT shall provide information on 
the media types, the SIP message bodies and SIP headers support. The information shall be included in 
«IVv'U-TO-IWU» information element which shall be placed in a {MM-IWU} message. If the information to be 
included into the «IWU-TO-IWU» information element will result in a {MM-IWU} messages longer than 63 octets, 
the «IWU-TO-IWU» shall be segmented and segments shall be included in one or more {MM-IWU} messages 
being sent after the first { MM-IWU } message. If no other protocol entities are using the link established for the 
execution of the procedure, the FT shall use "partial release" (see EN 300 175-5 [5], clause 14.2.7.2) to maintain the 
link open for receiving all messages from the PT. 

After collecting all {MM-IWU} messages the FT shall store the relevant information in the PT's record and may use it 
whenever appropriate, e.g. to execute/respond to SIP OPTIONS method, to ring a PT that supports specific type of 
media for a session that requires it. 

A voice only capable PT needs not to support this procedure. A PT that does not support the procedure will normally 
ignore the request. The omission of an answer shall be treated by the FT as indication of voice only capabilities. 

7.3.6.2 PT indication of capabilities 

A PT may optionally inform the FT for its capabilities without an explicit request from the FT. If supported PT shall 
provide its capabilities to the FT during or immediately after the SIP REGISTRATION procedure (clause 7.3.2). The 
information shall be included in «IWU-TO-IWU» information element which shall be placed in one or more (when 
segmented) {MM-IWU} messages. 
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7.3.6.3 



PT initiated query for remote terminal (client) capabilities 



PT may optionally provide to the user the capability for querying the media and SIP message body capabilities of a 
client. 

NOTE: FT may execute the OPTION method towards the SIP network independently from PT's request. When 
this may be done is left to the FT designer and to the requirements specified in SIP (RFC 3261 [18]). 

For query of a client capabilities the PT shall use the DECT External protocol information procedure as defined in 
EN 300 175-5 [5] clause 13.9. The PT shall include in the {MM-IWU} message a «IWU-TO-IWU» information 
element indicating SIP TERMINAL CAPABILITIES and providing the Request-URI (see RFC 3261 [18]) of the client 
(<To>) and optionally an indication of what type of message body is expected. The default message body type is 
"application/sdp" and shall be assumed if not included. 

Upon receipt of this message FT shall initiate on the first possible occasion a Query for capabilities procedure towards 
the relevant client. The received 200 (OK) SIP message shall be mapped to a «IWU-TO-IWU» information element 
included in one or more (if segmented) { MM-IWU } messages which shall be sent back to the PT. Some of the 
information received may have significance only to the implementation of the SIP protocol in the FT and need not be 
submitted to the PT. 

7.3.6.4 Message mapping 

7.3.6.4.1 DECT-SIP message mapping 

Table 41 : SIP registration messages list DECT-to-SIP 



Item No 


DECT Message 


SIP Message 


Map status 


Reference 
GAP 


1 


MM-IWU 


OPTIONS 


M 


N/A 



Table 42: SIP registration messages list SIP-to-DECT 



Item No 


SIP Message 


DECT Message 


Map status 


Reference 
GAP 


1 


OPTIONS 


MM-IWU 


M 


N/A 


2 


200 OK 


MM-IWU 


M 


N/A 



7.3.6.4.2 



DECT messages/information elements mapping 



For the structure of the «IWU-TO-IWU» information element the requirements in EN 300 175-5 [5] and annex A of 
the present document apply. Here only the requirements in regard to SIP capability query/indication are indicated. 

Table 43: «IWU-TO-IWU» 



Field 


Sub-field 


Value 


Comment 


S/R 




1 




Action 


Ext 


1 


Multi octet extension 




Value 


0001010 


SIP TERMINAL CAPABILITIES 


Body 




Not included 


FT shall not include <Body> in the request for the 
PT's capabilities 






All relevant (see 
below) 


Contains Fields from a SIP Message formatted 
according to RFC 3261 [18] using IA5 character 
set with the additions/modifications as specified in 
the present document. 
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Table 44: «IWU-TO-IWU» Body 



Field 


Format/Comment 


Support 


PT to FT 


FT to PT 


PT 


FT 


FT 


PT 


Message-Header 


For the support of the different Headers see the table 
Message-Header fields support below. 


M 


M 


C1 


C2 


Message body 


For the support of different Message bodies see the table 
Message-body fields support. 


C1 


C2 


C1 


C2 


C1 : IF request X, ELSE M 
C2: IF request 1, ELSE M 



Table 45: «IWU-TO-IWU» Body: Message-Header fields support - REQUEST 



Field 


Format/Comment 


Support 


PT to FT 


FT to PT 


PT 


FT 


FT 


PT 


To 




M 


M 


X 


1 


Accept 


"application/sdp" 


M 


M 


M 


M 


Accept-Encoding 
















Accept-Language 


(see note 1 ) 
















"en" 


M 


M 


M 


M 


Content-Length 


(see note 2) 


M 


M 


M 


M 


NOTE 1 : All terminals shall support content language "en" and the omission of language indication shall be 

understood as indicating Content-Language="en". 
NOTE 2: Requests shall not include message body, therefore the Content-Length shall be set to "0". 



Table 46: «IWU-TO-IWU» Body: Message-Header fields support - RESPONSE 



Field 


Format/Comment 


Support 


PT to FT 


FT to PT 


PT 


FT 


FT 


PT 


Accept 




M 


M 


M 


M 




"application/sdp" 


M 


M 


M 


M 




"text/*", "image/*", "audio/*", "video/*", "application/*" 














Accept-Encoding 
















Accept-Language 


(See note) 
















"en" 


M 


M 


M 


M 


Content-Encoding 
















Content-Language 


(See note) 
















"en" 


M 


M 


M 


M 


Content-Length 


>0 


M 


M 


M 


M 


Content-Type 


"application/sdp" 


M 


M 


M 


M 


NOTE: All terminals shall support content language "en" and the omission of language indication shall be 
understood as indicating Content-Language="en". 



The requirements to FT and PT respectively of provision/understanding of SIP message body is indicated in table 
below. Message bodies are allowed only in RESPONSE to a query of capabilities. 

Table 47: «IWU-TO-IWU» Body: Message-body support - RESPONSE 



Field 


Format/Comment 


Support 


PT to FT 


FT to PT 


PT 


FT 


FT 


PT 


Message Body 


All capabilities described in the form of a session 
description as defined in SIP (RFC 3261 [18]) and SDR 
(RFC 2327 [19]) using IA5 character set 


M 


M 


M 


M 



£75/ 



62 



ETSI TS 102 265 V1.2.1 (2004-10) 



Table 48: Values used within a IVIM-IWU message 



Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Segmented 
lnfo» 






Mandatory only if the IWU-INFO 
message will exceed 63 octets. For the 
requirements in regard to the usage of 
this IE see EN 300 175-5 [5] 




<Segmented element 
type> 


1110111 


«IWU-TO-IWU» 


«IWU-TO-IWU» 




All 


For the content of the «IWU-TO-IWU» 
information element see above 



7.3.7 U-plane support/provision 



7.3.7.1 



GAP u-plane 



Voice (audio) services on the DECT air interface shall be provided through a GAP call setup (with the modifications 
specified in the present document), shall use a GAP transport bearer and shall comply with the U-plane requirements as 
specified in EN 300 444 GAP [13]. 

A single voice stream can be handled during one GAP call. 



7.3.7.2 



DPRS U-plane 



Non voice (audio) services on the DECT air interface may be provided through a DPRS call setup (with the 
modifications specified in the present document), shall use one or more DPRS transport bearer(s) and shall comply 
with the U-plane requirements for the DECT generic media encapsulation transport mechanism as specified in 
EN 301 649 DPRS [16]. 

Simultaneous non voice streams can be handled during one DPRS call. 



7.3.7.3 



ODAP U-plane 



Non voice (audio) services on the DECT air interface may be provided through a ODAP call setup (with the 
modifications specified in the present document), use an ODAP transport bearer and comply with the U-plane 
requirements as specified in or TS 102 342 ODAP [32]. The relevant IP media protocol, e.g. RTP shall be placed 
immediately above the ODAP Data Framer. 

A single media stream can be handled during one ODAP call. 

NOTE: The ODAP option provides a low-data rate option (about 30 Kbps) and may not be suitable for all types 
of media. 
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7.4 Quality of Service (QoS) 



Implementations that comply with the present document shall, in the case of voice services, implement code conversion 
in the DECT Fixed Part. This means that the DECT ADPCM voice service shall be used over the DECT air interface 
and DECT voice samples shall be transcoded to/from the voice-over-IP data to be sent out to the IP network or received 
in at the DECT FT from the IP network. 

NOTE 1 : The main advantages of this approach are that the IP overhead is removed and a minimum delay can be 
guaranteed. 

For non-voice media, implementations should consider introducing resource management as specified in 

EN 301 649 DPRS [16] to allow fare distribution of resources among all DECT participants to one or a number of 

simultaneous SIP sessions, as well as, utilization of the DECT air interface for other, non SIP related, activities. 

NOTE 2: This version of the document does not study issues, if any, that may arise in regard to streaming real time 
media transport and does not provide requirements/recommendations. It is assumed that the DECT 
Dynamic Channel Selection (DCS) mechanism together with an well implemented DPRS resources 
management would be sufficient to guarantee QoS in this case as well. 

From DECT point of view it shall be noticed that the exchange of SIP related information on the DECT air interface 
may result in long «IWU-TO-IWU» information elements and their segmentation. Future versions of the present 
document may consider SIP information compression mechanisms. 
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Annex A (normative): 
IWU-TO-IWU specification 

A.1 General 

This annex summarizes the coding of <IWU-TO-IWU» information element introduced into the present document and 
distinguished by the <Protocol Discriminator> indicating "DECT access to IP networks". For the general structure of 
the «IWU-TO-IWU» see EN 300 175-5 [5]. 

Table A.I : «IWU-TO-IWU» 



Field 


Sub-field 


Value 


Comment 


S/R 




1 




Protocol Discriminator 




100100 


DECT access to IP networks 


Action 


Ext 


1 


Multi octet extension 


Value 


1000001 


IP Mobility: DIMS 


1000110 


IP Mobility: Authentication Payload 


1000100 


IP Mobility: Authenticator 






1001000 


IP Mobility: Registration 






1001001 


IP Mobility: Call establishment 






0000010 


SIP REGISTER: Adding/Modifying bindings 






0000011 


SIP REGISTER: Fetching bindings 






0000100 


SIP REJECT 






0001000 


SIP SESSION ESTABLISHMENT 






0010001 


SIP SESSION MODIFICATION 






0010010 


SIP TERMINAL CAPABILITIES 


Body 


All 


All 


The content of this field depends on the settings 
of the Action Value and is described in the 
relevant clauses of the present document. 
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